Yeah, it does work, and no i didn’t seth the hitbox’s raycast params to whitelist. My only issue is when Im running through a gameloop and then when I wanna equip a sword, the damage doesn’t work correctly. But however, if I equip the tool outside the gameloop, it does work.
Its just a bit buggy when I equip the sword to the player, the damage sometimes doesn’t work, I can drop you a download example if you like.
Sure, I can take a look at the example place. You can shoot me it in my DMs.
Hey, found the problem. It was my mistake, so my game loop was designed so that it teleported all the players humanoidrootparts using position not CFrame, therefore messing up the positions where the rays were casted.
3 Likes
Hello,
Any ideas on why it doesn’t hit some of the times on certain angles ? Thank you ^^
Hello!
I am trying to make a parry system where if you press a certain key, it will activate the parry. If player(A) attacks player(B) that is parrying, player(A) won’t be able to move for a few seconds. What do you think the best way to do that?
1 Like
Looks like it isn’t taking into consideration the hat when it gets hit (from what I see at least). There is also currently a little glitch with the red line visualizer that can make hit detection less accurate (will be fixed sometimes today), so try turning off the red lines and hitting normally at the angle to see if it persists.
1 Like
Seems like a topic this broad would be better off in development discussion or scripting support, but I’ll give some insight anyway.
My game uses a similar styled parry system where one can parry another. There are a few ways to achieve this.
-
A “hurtbox” of sorts. When player B parries, an invisible brick (or you can use attributes here somewhere for the player B) will appear alongside their weapon. You can then see if PlayerA hit this hurtbox, which if they do, they are parried. This is the most accurate way of seeing parries.
-
Animation checking. When player A strikes player B, instead of dealing damage, check if player B is playing the parry animation. Downside is that this method can sometimes be unreliable.
-
Status effect (personally how I do it due to the sheer amount of enemies in my game). Player B, upon playing the parry animation, is tagged with a “Parry” status effect for a second. Player A strikes Player B, and seeing that they still had the Parry status effect, becomes parried. This same logic can also be simplified wholely with attributes.
There is no right or wrong way to do it so it will be up to your own preferences.
1 Like
Is there any way I can optimize this?
https://gyazo.com/28ad894f9e1d54a0fbdbb5e34b9d1549
The rays don’t appear as fast as I’d like them to. Is there somewhere I have to edit?
If this is server-sided, that is latency you are experiencing and there are no known ways to fix this other than porting your hit detection to the client.
1 Like
How would i go about using GetHitbox on a part through a localscript?
This is the current code that i have, the hitbox is initialized but the variable hitBox is still nil
hitBox = RAYCAST_HITBOX:GetHitbox(character:WaitForChild(“Axe”))
Any help would be appreciated.
If the hitbox is initialized on the server-side, the module will not be able to see it. You will need to manually initialize the hitbox on both server and client. The hitbox also disappears when the Axe is deleted or destroyed (or respawns with the character) so reinitialization is needed.
1 Like
Are there any templates that have both client and server-sided hitboxes? I’m curious because I’d like to look into this and also because I don’t have a wide scripting knowledge.
You would basically do the same as you are doing now, though instead of using a script, you use a Localscript in one of these locations.
Localscripts will automatically launch a client-sided environment and is not affected by latency or server responsiveness, making it buttery smooth. Here is an example I did for another user that showcased the latency difference in a server or a client environment:
Leaving it client-sided allows the player to have full accuracy of this module while retaining no noticeable delay. When the client hits a target, you can use a RemoteEvent to send the target they hit to the server so the server can see if the target is valid.
However, this can open up security holes as clients can spoof RemoteEvent calls, and can basically send false targets (ie. the client tells the server to damage this target, but that target is 100 studs away from the player. Obvious red flag!) You would need to implement sanity checks on the server-side to prevent things like this.
2 Likes
So basically convert the script to a localscript?
Finally got it working, im very thankful for you releasing this module to the public you are a saint.
1 Like
Yes. While seemingly simple, I recommend familiarizing yourself with the limitations of localscripts. Overall, it shouldn’t take too much effort if you are already familiar with scripts in general.
1 Like
HI,
Relating to getting it going on the client side, after that is accomplished and some spoofing checks are added, what are some of the downsides of the limitations of localscripts, relating to this module that you are aware of?
Thanks
After using this module for a while, I found out that one of my lightsabers had this issue where the rays were casted in the incorrect spot. This only happened for the regular saber and I’m not sure what could’ve caused this, here’s some footage.
https://gyazo.com/ed895ae3c88a66b5df478b2b36cac72d
As you can see, the lightsaber is swung down, but the rays are casted to the left if that makes sense.
https://gyazo.com/bf3a4ed7c957a9a9f2b8514dbe33c5b2
Okay, so apparently tweeting the HRP caused this.
1 Like
I’m currently working on a new game, does this work with fists?