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…