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.
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?)
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.
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.
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?
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.
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.
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.
