A bit hard to see without debugrays on. How far apart are your damage points? Do you have an example place I can test on?
7 Likes
Turned Debug mode on, here is the place link:
5 Likes
Thanks for the place link. I only played for a few minutes before I had to go, but I’ll give some insights. Hopefully it improves your experience with the module.
This module is insanely accurate, and this in turn is a double edged sword and you will have to develop for it. Something to keep in mind is the positions of the points. Let’s take this image as an example:
To improve accuracy, you can perhaps make the sword swing animation “follow-through” a bit more, so the debug rays look more in line with the shape of a circle instead of a half circle. You can also put points on the handle, so if you are right up close to the enemy, it would still hit. The problem I feel is that the animations emphasize the hitboxes on the left and right side of the character instead of forward.
If you feel there is still some sort of performance latency going on, you can switch this module client sided and hear for OnHits. Then you can fire a remote to the server telling it to damage the humanoid.
Great looking game by the way.
12 Likes
what about performance costs? what’s the impact that it could possibly do if there’s multiple instances using this.
3 Likes
Is this an efficient way to use this?
local Hitbox = raycastHitbox:Initialize(model, {player.Character})
Hitbox.OnHit:Connect(function(hit, humanoid)
print(humanoid.Parent)
end)
Hitbox:HitStart()
wait(.3)
raycastHitbox:Deinitialize(model)
8 Likes
This depends on the amount of raycasts you are making per hitbox. Running 50 hitboxes with 10 raycasts each is probably better than running one hitbox with 500 raycasts, though generally good performance all around (even better if client sided)
You would want to use deinitialize like destroy. If you have objects you are going to delete or you are sure you will never use hitboxing again for it, this is what deinitialize is for. If you are going to use the same hitbox, the more efficient method is to call hitstop, and then when you need it again, hitstart. But generally yes, that is the way to do it.
10 Likes
Is there any way I can define
local Hitbox = raycastHitbox:Initialize(model, {player.Character})
in another script and call
Hitbox:HitStart()
in another script?
6 Likes
Untested as i dont work with modules all too often, but try to initialize in one script, and then in the other script, require the same raycast module, and then use
local Hitbox = RaycastModule:GetHitbox(your instance here)
If its not nil, you can use hitstart on it. If its nil, then I can try to make it work in a future update.
5 Likes
How does the RaycastHitbox:DebugMode work?
I don’t really understand it
3 Likes
Refer to the bottom of this post:
DebugMode is intended to show the raycasts being performed on the hitbox so you can see how your hitbox is interacting with the world. It helps you tailor your hitboxes better in regards to sizing, placement of nodes and anything in regards to fixing or testing your hitboxes.
2 Likes
Swordphin123 has added a line that can enable or disable the debugmode inside a script
That is what i don’t know how it works
1 Like
Its a simple boolean on off switch
RaycastModule:DebugMode(true) --turns on rays
wait(5)
RaycastModule:DebugMode(false) ---how quaint, somehow this turns it off!
Hope that helps.
8 Likes
Does this have to be used in the same script as the script that makes the hitbox?
And is it possible to set it true via a localscript inside a gui?
1 Like
I haven’t tested it with another script, so preferably it should be used in the same hitbox script.
But you can try to require the same module in your gui script and then see if DebugMode works in there. The RaycastModule will have to be client sided then for it to work.
If that doesnt work, you most likely have to use a bindableevent or remoteevent depending on your needs.
5 Likes
Alright thank you for your help.
3 Likes
I don’t know if a feature like this has already been suggested but it would be nice if you could add a feature where rays are created in between two attachments.
For example, if I had 2 attachments on a sword and 1 attachment was on top and the other attachment was on the bottom of the sword, there would be rays created in between those two attachments with a variable that could decide how far each ray would be apart.
This is a great module nonetheless and I’m planning to implement it into one of my upcoming games.
6 Likes
Hello,
I’m quite new to raycasting, so I’ve got a question (I haven’t seen this asked before). Do I need to put this script in a local script and then use a remote event to damage or do I cast the rays server side?
Thanks for your help,
Kees
1 Like
It’s personal preference. Put it on server side if you desire more security but less responsive gameplay, or put it on client side to have the ability to gain instant feedback (and make your combat feel a lot more snappier) in turn for more security checks (and generally a bit more work, using remote events, distance checks, angles, etc).
If you use the damage arguments instead of the OnHit connection line built into this module, then you will have to use it server sided.
7 Likes
Since the hit method is determined by casting a ray from the current attachment position to the previous one every frame, how would you safely do a distance check for that on the server?
4 Likes
Just a distance check probably won’t be enough, assuming you are using this client sided, and are using a remote event to tell the server “Hey, I damaged this enemy”. A potential exploiter can simply just call an entire different target across the map, and when the server receives this input from the clients, it should always check distance, be it magnitude or regions.
Recognize common sense in your game, such as an enemy should never be damaged 50 studs away if your swords are only 5 studs in length.
You can also combine distance check with angle checks. For example, to make sure you aren’t actually damaging someone close to you but directly below you.
These checks aren’t necessary if your hit methods are already all server sided and if that’s the case, efforts should be made to optimize it instead so your players can get the best responsiveness out of it. There can also be some potential exploits even on the server side, mostly teleportation or position based, so you should check for velocity or position differences here on top of any other checks.
8 Likes