Hi,
I’ve got another question. Can I also use raycasting(And this module?) for firing projectiles and other ranged attacks? Or should I then use touched or something else instead?
Thanks for your help,
Kees
Hi,
I’ve got another question. Can I also use raycasting(And this module?) for firing projectiles and other ranged attacks? Or should I then use touched or something else instead?
Thanks for your help,
Kees
I’m really grateful for this module since I’m not the best when it comes to hitboxes for melee weapons, you did a grate work
Interesting design, Keep up the work!
If I am understanding correctly, yes you can use other raycasting methods in combination with this module. I personally use this and also FastCast (another raycasting module) for my games.
Is this limited to only weapons? Or can we use this to make our own collision system for parts that are cancollide false?
No, this shouldn’t be used for that, there are ways to detect touch for non CanCollide BaseParts
I was just looking at this in detail. One of the reasons I didn’t implement something akin to this in FastCast was because there are certain drawbacks to this method (namely what I refer to as “hit resolution”, which refers to the spacing between each ray – If there’s a tiny part, there’s a chance it could be entirely missed or hit in the wrong spot, and moreso, finding out where the object would have hit if it were continuous would be very difficult, especially if projectiles were intended to have rounded ends or something like that – think of it like trying to represent a ball with a bunch of needles, where you need to preserve that curved surface but you can’t use too many needles).
One internal prototype I had for projectile width over in my module is a method I dubbed the “star method” which effectively emulates an explosion with rays (I had also lightly considered using an actual Explosion
object coupled with its Hit
event), but this method proved to be inaccurate for the desired goal (namely the reason being super fast bullets tend to have long rays which means they need insanely large explosions which can cause a lot of lag to test parts with). Given that swords travel nowhere near as fast as bullets, you may be able to get away with this method in your module.
Effectively, at the end point of every ray, create an explosion with r radius, and detect what that explosion hits. Set its pressure to 0 so that it doesn’t do anything, and set its type to NoCraters
so it doesn’t harm terrain. This could potentially reduce the number of attachments necessary, but you’d need to do math to calculate if the explosion hit should be a registered sword hit. It would give you the benefit of ranged detection. The math to determine this might be to make the user physically design a hitbox or set of hitboxes for their sword or whatever, then use math to find out if the explosion hit point intersects with that box.
Note: The ray test (pink) is flawed – If the center of the explosion is inside of the part, the ray will register no hit. Be sure to test for this too.
Here’s a potentially relevant page for that math: https://yal.cc/rot-rect-vs-circle-intersection/
Could you release a base model that uses this module?
Are they able to detect individual body parts? Let’s say I was doing accurate dismemberment with lightsabers, how would I go about detecting the limbs on contact of the blade?
The module will return the part it hit when there is a humanoid found within it’s parent model. Though, it will only return one part at a time until you call HitStop, which it will reset and is ready to call another limb to hit again.
For greater control and to get all parts hit in the ray’s line of fire (and potentially more performance overhead) turn on PartsMode in the module, and it will act like a normal .Touched.
Why does the hit function fire on EVERY part it hits?? How can I get it to just fire on a single model, not all the parts??
Because if I do like this
local function Hit(hit)
print('Hit')
end
NewHitbox.OnHit:Connect(Hit)
And hit say a single part model, it prints Hit once, but if I go to a model that might have several parts in it, it will print for each part it hits, thus doing more damage than just a single hit
Why does the hit function fire on EVERY part it hits??
To have a better understanding, you should read this and create an if statement that only works if a previous part that was hit is not from the same model to prevent the hit from activating multiple times.
Make sure PartsMode is disabled.
Edit: If it is still doing that, please provide a simple repro place that can replicate this behavior and I’ll take a look.
I have parts mode turned on, as I’m dealing with like objects (using this for like axes/pickaxes and detecting hits on blocks)
Then it is working as intended with PartsMode. It is like touched, you will have to supply your own model ignore list and to detect that you are not hitting the same humanoid twice.
Using a debounce and what not won’t work tho
if CurrentHitting then return end
CurrentHitting = hit.Parent
print('Hit')
CurrentHitting = nil
Would still prints multiple times
I just use bounding box collision checks within a whitelist.
It works efficiently and accurately.
try adding a wait(n) below the print
Will this module be getting updates anytime soon? I used it in a test melee system and it worked very well with no bugs besides 1 small one that randomly occurred. I would love to use this in my next project but it’s not viable if this is discontinued, so please think about giving it a bunch of updates.
Not sure what updates you are expecting, other than additions. It is considered feature complete and will probably remain in Beta until the next addition (which does not have an ETA due to my tight schedule). After that, it probably will no longer be updated and any future additions will have to be done by the user.
I will still publish bug fixes but that will be the extent of my support for this module. I am planning on making Spherecast-like hitbox system but that will probably be for another module.