How big should the part be for the module to be accurate if I wanted to create a fist-style combat?
I don’t know how large I should be welding into an R6 arm
I’m not sure what you mean? This does not use parts for hit detection, it uses raycasting, which is an infinitely small width with a predetermined length. You don’t need to weld anything.
Oh, I must have misinterpreted since I saw someone in the comments talking about welding for a fist-style combat
My apologies but how would I use this to create a hitbox for a fist-styled r6 combat?
I’ve put some tutorials up in the original thread but you would use Attachments and place them in your R6’s arms. The raycasts will follow their position.
Ah, now I understand! Thank you for the help
V.4.0 Stable
There’s a lot to write about this update, but long story short, the module got a big overhaul. To the way it works and to the way it is written internally. This includes API changes, optimizations, lowered memory usage and of course, new features.
Mesh Deformation
This is one of the major reasons why V.4 took a while to release. A lot of the time was spent optimizing the module to work with bones. There isn’t a lot to really write home about here, it’s quite rudimentary for now since Roblox bones don’t support much functionality. Only SetPoints is supported for Mesh Deformation.
hitbox:SetPoints(bone, {Vector3.new(0, 10, 0), Vector3.new(0, -10, 0)})
Detection Modes
This supersedes PartMode, making it the new way to customize how the module deals with hits. Refer to documentation DetectionModes for more information.
Improved Debug Ray Visualizer Performance
I think the framerate comparisons below say for themselves. RaycastModule relies entirely on the framerate to determine hits, so having the rays not become a bottleneck to that is quite important to me. Hopefully, this will make your debugging sessions easier!
OLD VERSION (Version 3.xx) - Test: 500 Raycast Points (Averages 13.5 FPS)
NEW VERSION (Version 4.0+) - Test: 500 Raycast Points (Averages 59.9 FPS)
Upgrading from 3.xx to 4.0
Please note that V4 is not backwards compatible with V3. There are a few API changes that were introduced in V4 to better suit modern code etiquette. Here are the changes you need to know if you want to make your code compliant with V4:
Changed: Creating a hitbox is now different
- Removed RaycastHitbox:Initialize
- Removed RaycastHitbox:Deinitialize
- Removing Initialize also removed the innate IgnoreList functionalities
Suggested Alternative:
- Use the new RaycastHitbox.new to create your hitboxes
- Use the new and improved Hitbox:Destroy to garbage collect your hitboxes
- Write to property Hitbox.RaycastParams with a proper RaycastParams. RaycastParams allows you to create whitelist/blacklists.
Changed: Method calls to activate certain hitbox functionalities has been removed
- Removed Hitbox:PartMode
- Removed Hitbox:DebugMode
Suggested Alternative:
- Use the aforementioned Hitbox.DetectionMode to set your hitboxes to Default, PartMode, or Bypass
- Write directly to Hitbox.Visualizer with a true or false to turn on or off the debug rays respectively
Changed: Minor raycastParams name change revision
- Renamed Hitbox.raycastParams to Hitbox.RaycastParams
Changed: Group names no longer support StringValues
- Hitboxes relying on group names in their attachments no longer uses StringValues
Suggested Alternative
- Group names now only supports attributes.
Where to get this new version??!!
The cool kids club:
The cooler kids club:
Example V4 playground place:
RaycastHitboxShowcaseV4.rbxl (107.4 KB)
Great update, though I have a question. I called Hitbox:Destroy() to recreate the hitbox on the same tool, yet it seems to be grabbing the hitbox that I destroyed from cache as the next Hitbox:HitStart()
errors with: attempt to call a nil value
. Is this something I’m doing wrong or an oversight?
I see that the one it seems to grab from its cache has PendingRemoval set to true. Is there any way to override grabbing it from cache? For now I just added my own cache override because I wasn’t sure if there was a way to override it.
Edit: Even after adding the cache override it still doesnt work for whatever reason I still get attempt to call a nil value
, even with a brand new hitbox made.
Here’s an example of what my code looks like, it works the first time InitHitboxes
is called, but any subsequent time gets the error:
Code
function InitHitboxes()
if Hitbox ~= nil then
Hitbox:Destroy()
Hitbox = nil
end
local params = RaycastParams.new()
params.FilterType = Enum.RaycastFilterType.Blacklist
params.FilterDescendantsInstances = {Character}
Hitbox = RaycastHitbox.new(Tool, true) -- true was the cache override I added
Hitbox.RaycastParams = params
Hitbox.DetectionMode = RaycastHitbox.DetectionMode.PartMode
local conn = Hitbox.OnHit:Connect(Hit)
table.insert(DisposableConnections, conn)
Hitbox.Visualizer = true
end
I have a specific reason as to why I’d need to recreate the hitbox in the same tool. But as I said, even with forcibly creating the new hitbox, it doesnt work after the second call.
Edit 2: So after looking at the internals of how hitboxes are cleaned up I saw they are in a heartbeat loop, so I just added a small delay before initializing new hitboxes and it worked.
Your code gets better and better each update.
Is there a way to do this server side without much delay? I know there will be at least a slight amount of delay regardless when doing this server side, but I don’t wanna have to do a whole bunch of security checks. So is there any way I can optimize this to make the rays quicker or something for server side?
@steven4547466 Thanks for the report. I uploaded a potential fix, can you check for me if it still happens without a delay?
@Icey_CD The delay is latency and unfortunately not a lot you can do to counteract it unless you put it client sided. Latency is just a byproduct of how our internet works, you can try to work around it but the internet isn’t instant. I have already optimized it to the fullest extents of my knowledge, using techniques directly from Roblox engineer responses, 2 years worth of performance testing, and thousands of hours in live game testing with hundreds of humanoids and players. You pretty much can’t get much faster than this, well, until Roblox releases more Raycast optimizations.
It now works without the delay, thanks!
SetPoints doesn’t rotate with bones
Seems like a bug with replication. Does that happen if you put the module client sided as a test? Would you be able to share that exact model to me so I can see if it’s something I can fix?
This issue has been fixed.
Sorry, me again. I noticed that OnHit only allows one connection. I also noticed that signal is set up to basically only be one connection. Is it ever planned to expand this to allow more connections? I plan on adding support for it regardless, but I just want to know if it was planned to add the ability to connect more.
Yeah it’s only one connection allowed at this time. Before you could have multiple hooked up but a lot of scripters fell into the trap of hooking OnHit every time they dealt damage which meant that OnHit will fire more and more times, at an exponential rate. So I limited it to 1 so its easier for newer scripters to grasp. This is my reasoning for limiting it. You are free to change that behaviour.
Small, tiny question, is there a way to use this on client? Without having the server to step in?
Oh, it works on the Client? That’s amazing.
Hello. I have followed the GitHub Wiki (Beginner Examples · Swordphin/raycastHitboxRbxl Wiki · GitHub), attempting to create a deadly part. However, it looks like the lines won’t appear and the Humanoid didn’t take any damage. Any help would be appreciated.
I think more information needs to be provided for a solution to your error.