Raycast Hitbox 4.01: For all your melee needs!

Resources Community Resources
, , , ,
#591

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.

#592

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

#593

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.

#594

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
#595

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
#596

Ah, now I understand! Thank you for the help

1 Like
#597

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
Realm of Ruin | Changelogs
#598

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.

#599

Your code gets better and better each update. :hot_face:

4 Likes
#600

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?

1 Like
#601

@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.

5 Likes
#602

It now works without the delay, thanks!

2 Likes
#603

SetPoints doesnā€™t rotate with bones :frowning:

1 Like
#604

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.

2 Likes
#605

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.

1 Like
#606

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.

2 Likes
#607

Small, tiny question, is there a way to use this on client? Without having the server to step in?

#608

I donā€™t see why you cannot use this on the client.

1 Like
Character sometimes doesn't get hit
#609

Oh, it works on the Client? Thatā€™s amazing.

1 Like
#610

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.