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.
Will this worked with lightsaber blades as well?
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.
I actually reached out to @TeamSwordphin around a week ago about how to make a system like this as I was very cautious. They responded to me within a few hours and helped me recreate it until I remade my own version of it. I highly, highly recommend using this module or at least this type of system. It solves a lot of common problems with making swords, such as if you should use a touched event or a raycast, as well as just helps makes your hit detection much more smooth and accurate.
Will you add support for multiple hitboxes in a single animation, registering by priority? (ex. Smash tipper hitboxes)
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.
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.
Sure. I guess I never really thought about making hitboxes on the fly (since I made it with the idea of having prebuilt weapons).
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.
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.
That’s exactly what I was talking about. Thank you, I will have to use this to make a Smash-style fighter now
How do you make this work with tools?
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.
Here is what I was talking about @TeamSwordphin, as you see there are hits that were not registered.
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?
Turned Debug mode on, here is the place link:
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.
what about performance costs? what’s the impact that it could possibly do if there’s multiple instances using this.
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)
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.