Will you add support for multiple hitboxes in a single animation, registering by priority? (ex. Smash tipper hitboxes)
8 Likes
Fabulous suggestion. Sure, I’ll add it to my to-do list for later. If you’re in need of this kind of feature right away, a workaround can be using two separate hitboxes, with two models for the blade hitbox and the tipper hitbox, and then listening to both OnHits of the hitboxes and keeping track of it so they don’t hit twice.
Edit: If this feature comes out, or if you’re implementing this right away, the “tipper” hitbox will need to be larger than the blade hitbox, just so it guarantees the hit first.
11 Likes
Can you also throw an alternative to attachments in on that list? I hate doing instance management so doing a “hitbox” using a table of Vector3s relative to a part’s CFrame would be fabulous.
11 Likes
Sure. I guess I never really thought about making hitboxes on the fly (since I made it with the idea of having prebuilt weapons).
12 Likes
Well, even using prebuilt weapons, the table based hitboxes would be easier for me to read and edit imho. It’s a convenience factor for me.
9 Likes
Version 1.2 Beta
Hi all. This is a somewhat small experimental update (since I don’t think I fully tested it in multiple environments) so I am hoping some of you guys can test it out for me and see how you like it, or if there are any bugs then you can let me know.
In summary, V.1.2 introduces some slight optimization improvements and a new HitboxObject function: HitboxObject:SetPoints(Instance part, table vectorPoints) (hopefully what @BraxbroRoblox wanted). Like what it implies, you can feed it a table of vector3 values which will act like your attachments, except without the actual instancing part. Instance part is needed as it will be using Vector3ToWorldSpace as it’s origin. The instance part doesn’t even have to be part of the actual hitbox either, it can be a separate other thing across the map if you wanted it to be. This is so if you’re making dynamic skills, it isn’t relying on the origins of HitboxObject itself. SetPoints can be used in combination with prebuilt attachments, or even without any attachments. Example code:
local RaycastHitbox = require(RaycastHitboxModule)
local NewHitbox = RaycastHitbox:Initialize(workspace.Brick)
NewHitbox:SetPoints(workspace.SomeOtherBrick,
--- Or can use NewHitbox.Object >> returns workspace.Brick
{
Vector3.new(1, 0, 0),
Vector3.new(0, 10, 50),
Vector3.new(-40, 10, 3)
}
)
Minor addition as well, you can now use RaycastHitboxModule:DebugMode so you can toggle on/off the rays at runtime.
19 Likes
That’s exactly what I was talking about. Thank you, I will have to use this to make a Smash-style fighter now 
7 Likes
How do you make this work with tools?
4 Likes
That’s something for the support categories. Replies sections of Community Resources at usually about feedback or questions about the resource itself.
Nearly all cases of working with the hitbox module are the same. With a tool, you’d activate the hitbox when the weapon is swinging while creating the hitbox during tool initialisation. Try it out yourself first; always good to try first before asking to save time and possibly learn something.
7 Likes
Here is what I was talking about @TeamSwordphin, as you see there are hits that were not registered.
6 Likes
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?
8 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.
13 Likes
what about performance costs? what’s the impact that it could possibly do if there’s multiple instances using this.
4 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