I for one think it makes your code quite a bit easier to understand.
If it’s not meant to be used, why is it there?
It’s super convenient
3 Likes
It was put in far before module scripts were. While _G and shared are not officially deprecated/removed, it’s still advised to use module scripts rather than storing everything in a shared table like that. Easier for other programmers to read a code base like this too if you collaborate. Since they can see the hierarchical tree structure of your code base.
Roblox doesn’t like to always remove features that are no longer necessary because by doing so they could inadvertently break a lot of games which still happen to rely on it.
9 Likes
Apologies for the late reply but in case if you still didnt fix it: if you dont see any red lines in the debug mode, there are a few possible solutions:
- You initialized the wrong model. If its a tool, you should initialize the actual tool, not the character as the tool will unparent itself from the character when you unequip it.
- Try V.1.21 if you dont have that. I fixed some weird tools compatibility on that version.
Initialization caches all points found made at the moment you call its function, so you cannot add or parent new ones until you deinitialize or use the setpoints function.
No this shouldnt be normal. It should be fine if its registering the hits but only damaging once.
5 Likes
I can’t even begin to explain how useful this is, I’ve been searching for something like this for my sword fighting related game. Thank you!
3 Likes
Does this mean that I should make a handle and some parts and add attachments to these instead of the player character? (How would I make a tool also work for the left hand?)
2 Likes
Can’t answer the first one for you since I didn’t develop this (nor have I played around with it as much as I’d like to have yet), but I can the second one.
Left handed tools work the same as right handed tools, just that you have to add more work. In the case of using a tool instance or not, the concept is that you’re welding a tool to the hand and then setting up certain events on that left handed tool.
A while ago, I made a really quick tutorial for basic left/right hand tooling (it is also the method Dungeon Quest uses to equip tools, of you’re familiar with that game). See here:
This is a good concept to start with. Any other left hand tooling systems or implementations are up to you to craft depending on your needs. I’ve come up with a dozen tool systems at this point honestly, there’s so many ways to make them.
10 Likes
Im not sure how your tools are setup, but if im imagining it correctly, if the attachments are already in the character when you initialized it, it should theoretically work regardless if the script runs from a tool or not. But you can probably try that way instead as its cleaner.
6 Likes
If you don’t know how to setup the red lines, First you add attachtments with the name “DmgPoint” (Or something like that)
Then you have to make a seperate script
And use the line
RaycastHitbox:Initialize(Instance model, table ignoreList)
Inside the Instance model you should put the part where the attachments are located (Atleast that is what i do) and idk about the table ignorelist
I hope this is what you mean
4 Likes
I have implemented this and my punch tool is working now, thanks for your help 
No idea why that didn’t work, I also believe it should. However colbert his method is working, so I just switch to that
Thanks for helping me
5 Likes
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
5 Likes
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 
3 Likes
Interesting design, Keep up the work!
3 Likes
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.
6 Likes
Is this limited to only weapons? Or can we use this to make our own collision system for parts that are cancollide false?
3 Likes
No, this shouldn’t be used for that, there are ways to detect touch for non CanCollide BaseParts
9 Likes
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.
Here's a crude graphical representation of the explanation.
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/
9 Likes
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.
6 Likes
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