Okay now I have to use it given that it’s an open source resource now. I absolutely have to.
From the moment I first saw those hitboxes in action, that became one of my new favourite development-related threads. Being able to work with the logic behind it is a blessing and I thank you very much for sharing this resource with the community.
Melee hitboxes are definitely a rising topic on the DevForum as developers are creating more melee-centric games and a common question throughout the forums is how to achieve accurate hitboxes while accounting for several factors, up to determining which method is most performant and suitable.
Setting the thread to watching to keep up with any discussion. Thank you so much for this.
Thank you! I planned on something like that but ran out of time to make yesterday If I have time today I will absolutely update it with that functionality.
This feature looks AMAZING! Completely ignoring the practical uses for is the ‘SwordShieldMan’ looks cool twirling around a sword covered with red laser beams (aka. hitbox thingies).
In terms of practical uses, I believe this is going to be amazing to use, especially since detecting the.Touched event on a low end device is… Ya know…
Unfortunately as much as I love the rays following the weapon I feel my players may not feel the same way so I guess I wont have that enabled in my projects
In conclusion just thank you, this is such a well made solution to one of the most irritating problems on roblox and I didn’t even have to go through a pack of harribos keeping my mind focused enough to script it!
Just to confirm, the thing about using the beams was a joke @ScriptingSupport
Ah thank you! Before I could reply to your DM, I see you already edited it so I’ll just reply here instead. Let’s start from the top.
There are some slight changes in the optimized version that I think are unnecessary, but overall I think it is ultimately an improvement. DebugRay code was copied directly from the raycasting wiki so take it up with the writers . Still at work, so I’ll look at the optimizations a bit more thoroughly later.
I assume you are talking about the SwordNShield NPC above. I’m not sure what you mean by vertical rays, but I suppose if I am visualizing it correctly, something like a ray starting from a sword handguard to the end of it’s blade tip. There is a possibility that you can increase performance with vertical rays like this, but speedy swiping motions will not have a guarantee that it will hit if the target are between the vertical rays between the last and current frame. This will be no different than using a touched event imo (faster physics = less likely to hit).
Automatic attachment generation sounds neat, and I can probably try something like that. Though this may become intricate and difficult if it has meshes or weird shapes, and may even reduce performance depending on its complexity.
Overall, for simple swords, I would just string the attachments along the blade, and maximum 15 of them. Though the SwordNShield NPC has no problem having over 180+ rays being made at once.
Can confirm, also went to an art school. Even Michelangelo will tremble at your pure brilliancy. Picasso lovers, watch yourself.
I do like the idea of vertical rays, in a way people can sacrifice accuracy for more performance so you’re right. Regarding block part as a hitbox, I suppose something like an irregular scythe weapon where the angles aren’t always rectangular and you want something especially accurate, it might not work but for most common use cases, I can see it working like you described.
Awesome module, however before i am going to use this ill be waiting for some more events to come out. I am currently creating lightsabers and i need the onhit event. So definately using this in the future!
Hey all, just updated some minor but beneficial changes to the module. You can read more in the “How To Use” and “Update Log” in the main thread if you want to know the changes. Thank you to those who have helped thus far, it was a great learning experience. I will keep updating it and optimizing as need be (and as much as I can within my limited timeframe!)
In summary, the Initialize function now returns a HitboxObject which you can use HitStart or HitStop on. It also has a new onhit function (example in the main thread). I’ve filled out some more information directly in the module, and the HitStart and HitStop used directly on the RaycastHitboxModule is deprecated (so use the returned HitboxObject instead). This variable system also allows you to manage multiple hitboxes, a good example is if you have a dual wielding sword character, you can disable hitboxes for one of the swords while keeping the other off hand on.
How computationally expensive is this? It doesn’t look too bad, but I imagine swords with large hitboxes (and many of them) would have a lot of overhead.
There are definitely room for improvements, but from what I’ve tested, the performance was a lot better than using Region3 and Touched (in large quantities). The ShieldNSword npc above stretched about 181 raycasts a frame, and even in live production games with a plethora of other computation happening, server was still very smooth, fps drops were minimal, and this is also tested with multiple SwordNShield npcs at once. Though, if you’re really worried, it doesn’t hurt to test it out yourself.
Edit: Most games dont really have oversized swords, so honestly you should be doing 7 - 15 attachments per weapon, 1 stud apart for the most efficiency. It takes hundreds of rays a second to even consider performance drops.
For some reason, was not efficient on my testing.
There are a few points you should certainly consider for next update.
Ignore should automatically include the terrain.
Support for multiple hitboxes, such that sword skill hitboxes are bigger than normal attack hitboxes
have damage with initialize function? Instead of passing it, every time you attack, you could have it set in the metatable.
If possible could you share a sword model that contains the sword (or any other free model scripted with this module) so that we could see how you require the module etc?
However, all in all, this module is really amazing and I appreciated trying it out, thanks!
What I’m currently using for touched event is setting a loop that gets the touching parts of a non-cancollide part in the tool, representing hitbox.
Thank you for your insights. What performance problems were you encountering in particular? I can probably do a quick mockup example later for you.
Regarding 2., V.1.1 should have support for multiple hit boxes, you just need a separate model containing those new attachments and then call initialize on that one. Unless I’m not understanding what you’re requesting then I apologize.
The raycasts are from old point to current point, yes?
If so, then rather than attachments there should be an option to pass a table of positions and a root part to do said positions relative to. This would reduce instance management and be preferable in my opinion.
Yeah, I edited the script so that the sword has is made of tables, each one being the hitbox.
And regarding performance, I believe the number of parts or the number of raycasts created/calculated were the reason for the lag.
Would really appreciate a quick example tool, thanks!
What was your setup? You’re usually capable of firing off hundreds of rays per frame without performance hits as short rays at inexpensive. Seems like a concern to me that you were experiencing performance hits with this, since to my understanding it does exactly that (short rays per frame).
I will try to use the module with no configurations to it once I get home, my table edits might be the cause to the performance hits.
If this works out great, it would save me a ton of performance as I’m working on a rpg, means hits are everywhere.
The module is generally catered towards any and all melee needs. A lightsaber is a form of melee weapon, so it definitely would work with one. I’d assume if you wanted special effects added though, that would be something you need to implement on your own.
Any hand-held item that can be swung and inflict physical damage is a melee weapon (that’s pretty much anything but I’m talking about game wise). Lightsabers are no exception.
If I have time today I will absolutely update it with that functionality.
. Still at work, so I’ll look at the optimizations a bit more thoroughly later.
