I think the problem is with HitStart(). If I let HitStart(animation.length) → the first hit sometimes not work, but if i let HitStart(0.6)–> the first hit always work .@TeamSwordphin. I have no idea why this happen
it does print animation.length =0 at first hit wtf while it still plays the animation. idk why this happens.
Edit: ok I found the solution. Put this to check animation.Length so that the first hit will always work. Im not sure if it canbe laggy tho. Can someone confirm
while true do
wait()
if animation.Length >0 then
break
end
end
update i put a print inside the raycast module to print points inside if condition so tht all is working
update 2: there was a problem in my loop (i made attachments for the vector3s,tested,copied the tool object while testing,pasted in studio and saw the attachments pressed f and they were quite far away from hitbox)
@crazygamer817 Additionally you can turn on Debug Mode to see where the rays are ending up. SetPoints indeed works like attachments where the position property is relative to the attached part. The only solution for this is to keep checking where the rays are ending up.
@Neotrinax Region3s, as far as I tested, is one of the more performance heavy methods to detect hitboxes. Raycasts are lightweight and Roblox already does numerous optimizations for them in the backend. So I’d say yes, it is a lot more performant.
@Punkalox1 Animation Length property always returns zero the first few seconds it loads from an animator. This is because presumably, it is still trying to calculate how long the animation is. I would advise loading the animation(s) immediately when the character spawns if this is the case.
Do you what way to load the animation(s) immediately when the character spawns?
I assume you are doing something in the form of loading the animation immediately when you want to play the animation, like so:
function onSwing()
local animation = animator:LoadAnimation(swingAnimation)
animation:Play()
hitbox:HitStart(animation.Length)
end
This does not guarantee the length to be immediately available.
What I would recommend doing is waiting till the animator comes up the first time the character respawns (if you are using a tool, you would simply wait for the humanoid). This is how I would personally load animations beforehand:
local character = --- your character here
local humanoid = character:WaitForChild("Humanoid")
local animator = humanoid:WaitForChild("Animator")
--- Preloads the animations at the start of the script using a table
local animationsTable = {
Swing = animator:LoadAnimation(swingAnimationObj),
Swing2 = animator:LoadAnimation(anotherSwingAnimationObj)
}
function onSwing(animation)
local animation = animationsTable[animation]
animation:Play()
hitbox:HitStart(animation.Length)
end
function mouseClick()
onSwing("Swing")
end
function useASkill()
onSwing("Swing2")
end
This is quite the rudimentary script and I wouldn’t copy and paste it line for line, but it probably should be how you should do your animations if the Length property is required. The more important takeaway here is to call LoadAnimation somewhere in the initial parts of your script, and not where you would want to use it immediately.
FIXED, sorry to bother you!
Collapse
Hi, @TeamSwordphin. I have an issue (see the following picture and a part of the code):
...
if self.Hitbox then self.Hitbox:Deinitialize() end
self.Hitbox = RaycastModule:Initialize(newWep.Hitbox)
self.Hitbox.OnHit:Connect(function(_, Humanoid)
print(Humanoid)
end)
for Name, Anim in pairs(Anims) do
if string.match(Name, "ClassAttack") then
Anim:GetMarkerReachedSignal("HitStart"):Connect(function()
self.Hitbox:HitStart() -- Error: function not found. (Line 69)
end)
Anim:GetMarkerReachedSignal("HitStop"):Connect(function()
self.Hitbox:HitStop() -- Error: function not found. (Line 72)
end)
end
end
repeat wait()
print(self.Hitbox)
until false
...
I have a script that swings the sword and when it reaches a certain marker in the animation, it will start/stop the rays. But I get this error:
The first few swings after the character spawns, it doesn’t error, but also no rays. All the swings after that shows the ‘attempt to call a nill value’ error.
My presumptions lies on the fact that the table changes from ‘Hitbox for instance …’ to {…}, which causes the error, because the function isn’t there or isn’t .__indexed. Any idea why this issue happens?
I tried debugging my code from the inside out and it keeps showing this error.
No, I haven’t messed with your module.
EDIT 1: Not parenting the hitbox part (aka the sword) to a descendant in workspace seems to removes the issue, new issue: I don’t have a sword now to swing.
What was the problem: the hitbox wasn’t welded to the sword, so it got destroyed once it reached Workspace’s hell.
so i fixed my loop and i did the stuff u said and its the same as before but the attachments are in the correct place and the rays are just far away
Maybe a shot in the dark, but try setting your NetworkOwner of the Hitbox (where the rays comeout) to nil. (nil = server)
it casts from server so i am pretty sure it does in server
But have you tried it? An unanchored part created by the server doesn’t calculate it’s physics when there’s a player nearby that can do the calculating for the server.
@TeamSwordphin I just found out that if I jump off cliff, the raycast will not follow sword. Do you know how to solve this. https://gyazo.com/a4b1ba1d4bbbbaa2fcb6d2c44695a97b
Looks like you are anchoring the character, even when you anchor the character they will still retain velocity and this could possible mess up the attachments positions which I’ve seen before with issues like fastcast bullets spawning under the workspace.
So set the characters velocity or now assembly linear velocity to zero when anchored and see if that works
Otherwise it’s a server to client replication issues idk just guessing at this point.
I tried changing to velocity to 0. It did not work. I feel it more like it’s a server to client replication issues
It does indeed seem like a server replication issue. If you are using this module server-sided, it’s definitely seeing the sword position differently on the server-side due to latency. Unfortunately there isn’t really a fix for this since technically there is nothing wrong from the module’s standpoint. I wouldn’t worry too much about this if jumping off a cliff isn’t the main part of the game. If you need accuracy, you should use this module client sided and send the hit target to the server as an alternative method (with sanity checks of course).
Yeah, jumping off cliff attack movement isn’t anything important. I was just curious about it.
Hello @TeamSwordphin, great module! I was thinking if you would like to be able to add a thing to your module I made when it is fully finished. It can be used instead of set points/ attachments because this will get the part size and make a grid with positions on it. (The small dots are handle adornments)
Hey I Recently was trying to make still hitboxes that would stay in place, but they won’t hit if the player is standing still (sometimes). The red lines appear and they all go throught the player but it won’t detect them. Thanks for helping.
local hitbox = game.Workspace.Part
local hb = RayHB:Initialize(hitbox)
for i , v in pairs(hitbox:GetChildren()) do
for i , k in pairs(hitbox:GetChildren()) do
if v ~= k then
hb:LinkAttachments(v,k)
end
end
end
hb:HitStart(.2)
hb.OnHit:Connect(function(hit,hum)
print(hum.Parent)
if game.Players:GetPlayerFromCharacter(hum.Parent) then
game.ReplicatedStorage.Events.ClassEvents.Class2.Ab2:FireServer(hum)
end
end)
That’ll be great! I’ll be sure to credit you once it’s finished! I know this will help a lot of people and save a lot of time!
@ncs03082 Looks like there’s a problem on how I wrote the raycastParams for the red line visualizers in the module. It actually does work but for context, the module isn’t ignoring the debug red lines (so therefore they keep hitting the redlines thinking they are actual targets). Try ignoring the terrain in the meantime (which is where the red lines are parented to) and see if it works:
local hb = RayHB:Initialize(hitbox, {workspace.Terrain})
This should be fixed in the next module update. Thanks!
The problem that @ncs03082 has, might also happen to many people so I was thinking you should use handle adornments to avoid the rays hitting the debug parts. Secondly, so that people that have other parts in parented to terrain would not have the parts blacklisted.