uhmm, you can use cframe:lerp or velocity, a lot of stuff lol
Check out an old post of mine, is how I make my own.
1 Like
It is, it works by setting the SpellParts LookVector into direction of the Mouse.Hit; it’s then moved forward along it’s LookVector until colliding.
@KossmoZ Is there a similar solution to this without so much loop? I mean it’s creating a lot of lag.
No love for TweenService? Well, I’ll bite. Basically, you’d use “Time Formula” (as highlighted here). It calculates the time based on the normal time of the tween (0.3 is what I’ve had the most success with), and you would multiply it by the magnitude of the difference between the projectile and the end position.
local tween = TweenService:Create(projectile, TweenInfo.new((mouse.Hit.Position - projectile.Position).Magnitude * TWEEN_TIME / TWEEN_VELOCITY, Enum.EasingStyle.Linear), {CFrame = CFrame.new(mouse.Hit.Position)})
tween:Play()
1 Like
I attempted this method and I quite enjoy it - How would I go about implementing an updating RayCast to detect collisions that will also remove my Part without delay?
The only other method I found was the one I mentioned above, but as said - It results in lag.
3 Likes
For me, I’d just hook it to a touched event and cancel the tween when the event is fired. If a humanoid is detected, then I’d take damage. Also, don’t forget to disconnect from the touched event when it’s fired.
Will the tweening reduce lag? And for the sake of argument… how would you connect raycasting to it?
He’s using Raycast to detect collsions with a projectile, however, in this case, Raycast collision detection is a overkill method for projectile hitboxes. It would make sense for melee, but it’s just best case scenario to use .Touched because none of the bugs are present in the situation.
And this will resolve some lag issues?
.Touched has always seemed to have a delay on it. Its the reason I began using RayCast to begin with - With RayCast and the method I used above, it made collisions seemless, although yes its not the most efficient.
However, using the Touched event seems to create a delay where the spell part appears to pass through the Player for a brief second before registering and removing.
I’ve had this before. My only issue with your previous method @KossmoZ, which i have been using… is it creates lag. Maybe its because too much is running through the code? would a repeate wait after the tween plays, detecting the ray be less taxing on the server if its only indexing the ray values… and hit values?
1 Like
I just tried the tweening thing… it doesnt seem to be triggerable for some reason. Touched isnt working, and i even tried for the sake of argument, loops behind the tweening just without the cframe moving with raycasting. 
not working.
1 Like
Apologies for the lack of indent as it was rushed.
Try this perhaps? Just an idea I had.
local RunService = game:GetService("RunService")
local RemoteEvent = Instance.new("RemoteEvent")
RemoteEvent.Parent = script.Parent
RemoteEvent.OnServerEvent:Connect(function(Player, TargetPos)
local SpellPart = Instance.new("Part")
SpellPart.Anchored, SpellPart.CanCollide = true, false
SpellPart.Size = Vector3.new(1, 1, 1)
SpellPart.CFrame = CFrame.new(Player.Character.Head.CFrame.p, TargetPos)
SpellPart.Parent = Player.Character
local IgnoreList = Player.Character
local SpellSpeed = 5
RunService.Heartbeat:Connect(function(step)
if not SpellPart then return end
wait()
local SpellRay = Ray.new(SpellPart.Position, SpellPart.CFrame.LookVector * SpellSpeed)
local Obj, Position = workspace:FindPartOnRay(SpellRay, IgnoreList)
if not Obj then
SpellPart.CFrame = SpellPart.CFrame + SpellPart.CFrame.LookVector * SpellSpeed
else
SpellPart:Destroy()
return
end
end)
end)
2 Likes
It’s definitely using raycasts with server-sides sanity checks. The projectiles are fired by the client and the distance is most likely traced by the server,
There’s a bunch of ways that you can achieve the zig-zag effect. One being, if you made a raycast from the wand’s tip to the part that’s hit (assuming that you’ve hit a part), you can think of it as the X-Axis of your graph where origin (0,0) is your wand’s tip. From there, you could create a sin-wave and have random values for it’s frequency.
thats interesting… and use the sin wave for the cframe values?
If you have an axis, chances are that you have a line. If you break the line into segments, you can change the points (sine waves treat these as frequencies) of which your peaks and valleys fall. The result is a zig-zag effect.
i’m taking a wild guess here, but maybe they tagged all projectiles using collectionservice and then used getTouchingParts when moving the object in a loop? I mean it works for larger projectiles as raycasts get messy for anything larger than 1 stud, and then when they use gettouchingparts they could just check if the part that is returned (or the part in the table that is returned) has the ‘projectile’ tag and then initiate clashing if it happens?
1 Like