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?
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.
Have you considered just using the Part.Touched property for your use case? It would save a lot of code.
I’m learning this just so that I can use raycast to replace over Touched events in the future where I need very fast projectiles to detect whatever they touched.
If you’re making very fast projectiles, I don’t see why what’s shown in the video would be an issue.
I may be wrong about this, but I believe the reason he/she is trying to find a replacement for the touched event is because of this post, a topic we both discussed in. We established that the Touched event does not fire when using TweenService on two anchored parts because TweenService merely updates a property over time. Because of this, @ItzMeZeus_IGotHacked suggested using Raycasting as an alternative, which leads me to believe that this topic is a result of his/her testing.
Reality check. Everyone in this thread is here because they want to help. Nobody is paid to be here. Nobody here can force you to do anything you don’t want. Filter the advice you don’t think is valid and move on, and flag it to the mod team if you believe its intentionally disruptive.
You’re totally valid in specifying constraints in your problem statement; however providing context for everything you ask about here can only help. If it’s raycasting projectiles you want, it’s raycasting projectiles you can get.
To answer your question… Instead of raycasting a short distance as often as possible, it would be more practical to last known and current positions of the attachment on a regular cadence, particularly RunService.Stepped. And it’s more than likely TweenService is causing problems, as tweens don’t necessarily make physics work like you’d expect.
So what do I do? Use these positions to cast out rays?
Tip: Just ALLWAYS draw the ray. I do. It makes debugging and 5 other things easier and there is no down side.
function DrawRay(origin, point) – 7 studs long
local Ray = Ray.new(origin, (point).unit * 7) --Make the ray.
local Hit,Position = game.Workspace:FindPartOnRay(Ray,AI) --Check for collisions along the ray, ignoring any Parts of us.
if true then --Graphics
local RayPart = Instance.new(“Part”,AI)
if Hit then
if Logic == 1 then
RayPart.BrickColor = BrickColor.new(“Black”) --Set its color.
else
RayPart.BrickColor = BrickColor.new(“Bright red”) --Set its color.
end
else
if Logic == 1 then
RayPart.BrickColor = BrickColor.new(“White”) --Set its color.
else
RayPart.BrickColor = BrickColor.new(“Olive”) --Set its color.
end
end
RayPart.Transparency = 0.2 --Set its transparency.
RayPart.Anchored = true --Set whether it will fall or not.
RayPart.CanCollide = false --Set whether people can walk though it or not.
RayPart.formFactor = Enum.FormFactor.Custom --Make it so it can be small.
local Distance = (Position-origin).magnitude --Find the distance between the hit and the torso.
RayPart.Size = Vector3.new(0.4,.2,Distance) --Set its size to the distance.
RayPart.CFrame = CFrame.new(Position, origin) * CFrame.new(0,0,-Distance/2) --Move it halfway.
game.Debris:AddItem(RayPart,2) --Add it to the debris.
end – Graphics
return Hit
end – DrawRay
Yeah. Something like this:
local RunService = game:GetService("RunService")
local attachment = script.Parent.Attachment -- or wherever
local lastPos = attachment.WorldPosition
RunService.Stepped:Connect(function (t, dt)
local currentPos = attachment.WorldPosition
local diff = currentPos - lastPos
-- (A)
lastPos = currentPos
local result = workspace:Raycast(lastPos, diff)
-- Process result as ncessary
end)
Protip: At (A) you can skip the next bits for performance if diff is sufficiently small (which means the attachment didn’t move, so there’s little need to raycast).
This seems believable, thank you for being smart at once. I’ll test it out later.
I heard a good quote the other day: "Which is more intelligent? This rock or a computer?
It’s close to a draw. Realize that; and debugging will be easier.
Sorry for the super late reply, your method works like a charm! Now all I need now is how would I use these attachments and position them…