Raycast Hitbox 4.01: For all your melee needs!

This hitbox requires movement and velocity of the user’s hitbox in order to register. If you are standing still, and enabling the hitbox without moving your weapon or person at all, there is no length to speak of for the hitbox to detect. The hitbox requires significant movement for it to be accurate. There is a LinkAttachments function in this module as well which can help your specific problem since it’s meant for stationary hitboxes.

Well, it’s moving the weapon but sometimes if you stand still when attacking it doesn’t detect anything. Oh and, how would I proceed to make the hitbox be able to detect even without movement and velocity of the user.

It’s hard to see what causes it since I don’t see where the rays are going (DebugMode turned to true will help me see that). It can be a few problems, like lag or not enough attachments.

Oh, the problem was because there wasn’t enough attachments on the sword. I fixed the problem, Thank you for your help!

1 Like

If you don’t mind me asking when will you be able to add my module? It is almost fully finished just need to add one feature…

Hello there, I tested this and it seems to be working fine. My problem however is when I play it, the ray only shows up once and not appearing anymore.


local RAYCAST_HITBOX = require(RS.RaycastHitbox)

local newHitbox = RAYCAST_HITBOX:Initialize(script.Parent)



newHitbox.OnHit:Connect(function(hit, humanoid)
    print (hit)
    humanoid:TakeDamage(50)
end)

newHitbox:HitStart()```

HitStart only draws the rays once. Similar to a toggle light switch. Use hitstart() to turn it back on, hitstop() to turn it off.


@rottendogDkR Been quite busy recently so I don’t have an ETA, and it also depends on the complexity of your module. I’m currently doing some additions to the RaycastModule which will support bone and mesh deformation so it may take a while.

1 Like

I will be making the complexity of the module more simple but thank you for letting me know.

1 Like

I need help with the module. (EDIT: Don’t mind the reply on post, I forgot how to reply to person only)

So, for some reason when I update from RaycastHitboxV2 to RaycastHitboxV3, the Handle3 I’ve created won’t work even though the first 2 will.

Example of the Handle3 still being present in workspace and the error in question:

What line 119 is:

image

The first two work perfectly fine, yet for some reason Handle3 will always error despite each function being set up the exact same as every other handle. I don’t understand this error and that’s the only reason why I’ve had to hold back on updating the module. Can you help explain how I could fix this?

image

I think you forgot a capitalzation! V3 removes old coding standards so that’s the only major difference.

1 Like

Hello, is there a way to change the default red lines to something of my own?

Yes, if you look in the CastLogics folder inside the module, there should be a module called Debugger. You can change the colour in there.

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?

1 Like

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.

2 Likes

Ah, now I understand! Thank you for the help

1 Like

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:

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

Changed: Group names no longer support StringValues

  • Hitboxes relying on group names in their attachments no longer uses StringValues

Suggested Alternative


Where to get this new version??!!

The cool kids club:

The cooler kids club:

Example V4 playground place:
RaycastHitboxShowcaseV4.rbxl (107.4 KB)

71 Likes

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. :hot_face:

4 Likes