Raycast Hitbox 4.01: For all your melee needs!

That is the debug trail to see where the raycasts are going. You can turn off DebugMode in the module settings itself.

1 Like

Thanks, but do you know how to make it work ONLY on people NOT in your current team?

1 Like

Since this module does not support team filtering, you will need to incorporate it yourself. There are a few ways to go about this. The first way can use the ignore list with Initialize to ignore the ally team:

local allyTeam = game:GetService("Teams")["My Team Name"]
local ignoreList = {} 

for _, ally in ipairs(allyTeam:GetPlayers()) do
     if ally.Character then
        table.insert(ignoreList, ally.Character)
     end  
end

local hitbox = RaycastModule:Initialize(weapon, ignoreList)

Another way is to use collision groups (each team has it’s own collision group which ignores itself) and using the hitbox’s raycastParams to ignore it.

local hitbox = RaycastModule:Initialize(weapon)
hitbox.raycastParams.CollisionGroup = myCollisionGroup

The last way can be checking merely on Hit (which is the classic way to go about things).

local allyTeam = game:GetService("Teams")["My Team Name"]

hitbox.OnHit:Connect(function(hit, humanoid)
     local targetPlayer = game.Players:GetPlayerFromCharacter(hit.Parent)
     if targetPlayer and targetPlayer.TeamColor ~= allyTeam.TeamColor then
          humanoid:TakeDamage(10)
     end
end)
3 Likes

I am using the module to simulate a barrage of punches in front of the character (yeah, JoJo game). I am being a bit lazy and not raycasting on each flying punch, but instead I just want a simple hitbox in front of the character that represents the area where the punches are landing.

I am using :HitStart() and :HitStop() fairly quickly, something like every .25 seconds but I notice that it will not register a new hit unless the ray attachments actually move. If I wiggle around and move the hitbox across the target, it will register hits just fine.

I have only thought of two ways so far to fix this, one is to actually CFrame the hitbox a tiny bit every time I cycle the :HitStop

Another method is maybe the Link Attachments? But I am not sure if they will register hits unless there is motion as well.

So in short, it seems that hits are only registered if there is motion, a non-moving HitPoint will not register a hit.

Am I missing something in my setup or thinking? Thanks!

1 Like

Apologies, this post contains some misleading or inaccurate information. I did forget about some of the API members and actually a way that this could work. Please view discussion below for a proper resolution. Idle hitboxes also work with this.

Archived post

This resource probably won’t be good for your use case. RaycastHitbox is primarily intended for moving melee hitboxes, moved with animations or because of actual physical movement.

You might want to think about opting for lightweight solutions, such as a single cast or some from your own attachment setup within the hitbox or from your NPC’s root part. You would also be able to cast as in when the arm thrusts out during the punch rather than calling HitStart and HitStop frequently across a small time frame (instantaneous and once > quickly toggled). It does mean losing a few of the goodies this module offers and having to make your own sort of module to help better work with your hitboxes.

It provides an interesting use case though. Toggle features, depending on what they are, come well equipped with a singls-use method as well. For example, ParticleEmitters have the Enabled property but then also Emit which will send out a number of particles immediately. Having a method native to RCHB which allows developers to cast a single time out from their attachments might be pretty useful for use cases like this.

I was sure someone might answer in this way, but this module is very useful to me in other ways throughout the game, I am more likely to try and make this work by wiggling the hitbox part in some way just to keep things “simple” than to use a separate solution for this one part of the game.

I guess I’m still curious if the Linked Attachments work differently because they have a ray stretched across two point instead of single points that require some motion to cast the ray.

Does anyone know if this is the case?

1 Like

Link attachments may work as it draws a ray between those two objects. As rays are, anything that intersects between these two objects is considered hit. However you do need to be aware that rays still do not detect hits if they start inside an object’s boundaries.

The reason it doesn’t register a hit initially is that HitStop will reset the point’s back to its current position, and when you call HitStart in such a short time frame, there is basically not a lot of time to compare positions from its last and current frame (so most of the time the ray will just have a length of zero).

3 Likes

Thanks for responding! So to clarify here, are you saying that a ray that crosses through a player completely (Linked Attachment) will not fire again when it is cycled through :HitStop / :HitStart?

1 Like

It will behave like a normal hitbox, similar to how the normal methods work in this module. It will hit a target once until you call HitStop again, which will then reset the target pool, allowing your linked attachments to hit again once you call HitStart. I would imagine this would work for your use case.

1 Like

OK! More questions :slight_smile:

Can we have link attachments in the same part? Your example on the Wiki shows two separate parts, but what if we have two attachments named Link1 and Link2 parented to the same part and then create the link via script, will this also work the same?

1 Like

Yes it will work. The actual part is not really needed, more important is the two physical attachments that you give the module.

1 Like

Great thank you! I tried setting up the Linked Attachments and in the end, the whole thing is starting to feel a little but Rube Goldberg for this use case.

The module is incredible as it is, but if I could add anything, it would be the ability to register a hit while the HitPoints are not in motion. Imagine a sword or lance stabbed through the target, doing damage continually as long as it is there.

Thanks for your support!

4 Likes

Guys I followed the tutorial on Github and made a part, put an attachment on it named “DmgPoint”, activated DebugMode, and put a script in it

-- << Initial Setup >> 
local RS = game:GetService("ReplicatedStorage")
local RAYCAST_HITBOX = require(RS.RaycastHitboxV3)

local newHitbox = RAYCAST_HITBOX:Initialize(script.Parent)

newHitbox:DebugMode(true)
newHitbox:HitStart()

now, the raycast message detected the attachment, but I couldn’t see the rays. Anyone know why?

2 Likes

I know it may seem obvious, but have you tried moving the part around? If rays are still not being drawn, make sure HitStop isn’t being written anywhere.

1 Like

Uh, for some odd reason, my hitbox.onhit function is unable to detect boolean values that are set outside and above that function.

function module.Swing(AnimTable, Tool, Damage, UserHumanoid, Hitbox, Special)
	local Handle = Tool:FindFirstChild("Handle")
	if Hitbox then
		local ChosenAnim = #AnimTable > 1 and AnimTable[math.random(1, #AnimTable)] or AnimTable[1]
		local TouchConnection
		ChosenAnim:Play()
		print(Special)
		ChosenAnim:GetMarkerReachedSignal("EnableHit"):Connect(function()
			Hitbox:HitStart()
			TouchConnection = Hitbox.OnHit:Connect(function(hit, Hum)
				print(Special)
				if Special == true then
					print("YEE")
					WeaponSpecials[Tool.Name](Hum)
				end
				Hum:TakeDamage(Damage)
			end)
		end)
		ChosenAnim.Stopped:Connect(function()
			Hitbox:HitStop()
		end)
	end
end

Hey!

I’m currently learning how to script, and I’ve been trying to learn how to make effective hitboxes. I mostly used raycasting, and the way my hitboxes worked is basically by casting 1 ray every time the melee weapon is activated/used. I usually cast the ray from the player’s humanoidrootpart, and although it works, it’s sometimes inconsistent, and it’s hard to calculate how far I want the ray to be.

Basically, the way your raycast hitbox works is by placing attachments in a melee weapon, and then raycasting all of those attachments at once whenever the tool is activated? I’m really curious about this

Assuming you are talking about the ‘Special’ boolean, seems to be working fine for me. I am using the following setup to test:

Details
A server script inside the tool
local RaycastModule = require(script.Parent:WaitForChild("RaycastHitboxV3"))
local Schwing = require(script.Parent.Schwing)
local newHitbox, userHumanoid

script.Parent.Equipped:Connect(function()
	userHumanoid = script.Parent.Parent:WaitForChild("Humanoid")
	newHitbox = RaycastModule:Initialize(script.Parent, {script.Parent.Parent})
end)

script.Parent.Activated:Connect(function()
	local Animation = Instance.new("Animation")
	Animation.AnimationId = "rbxassetid://6017466008" --- Example
	Schwing.Swing({userHumanoid:LoadAnimation(Animation)}, script.Parent, 5, userHumanoid, newHitbox, true)
end)
Same module as you are using
local module = {}

function module.Swing(AnimTable, Tool, Damage, UserHumanoid, Hitbox, Special)
	local Handle = Tool:FindFirstChild("Handle")
	if Hitbox then
		local ChosenAnim = #AnimTable > 1 and AnimTable[math.random(1, #AnimTable)] or AnimTable[1]
		local TouchConnection
		ChosenAnim:Play()
		print(Special)
		ChosenAnim:GetMarkerReachedSignal("EnableHit"):Connect(function()
			Hitbox:HitStart()
			TouchConnection = Hitbox.OnHit:Connect(function(hit, Hum)
				print(Special)
				if Special == true then
					print("YEE")
				end
				Hum:TakeDamage(Damage)
			end)
		end)
		ChosenAnim.Stopped:Connect(function()
			Hitbox:HitStop()
		end)
	end
end

return module

Ensure you are not fetching a hitbox that is created from a client or vice versa (ie. trying to fetch an initialized hitbox done by the client on the server).


@Crescendee

Yes, each heartbeat frame will run an entire iteration on all cached attachments. There is a bit of misconception being that people think that this module has a predetermined length the rays start off with when in reality all it does is check positions between the last frame and the current frame and draws a ray in between. Thus, the length is determined entirely by the speed of your hitbox movement. If your hitbox is unmoving, the length will be exactly zero.

2 Likes

I think it’s the get marker reached signal, then, that seems to run multiple times. If that’s the case, I don’t know why that happens.

1 Like

Yeah, if you aren’t destroying the animation or detaching the getmarkereached, I believe you are creating a new event for it every time.

1 Like

Hey, im curious as to how this works, and am seriously considering this for my game, however to my current understanding, when player swings, i have to call hitstart, and when the hit/animation ends, call hitstop. is this correct?

also what else should i be considering?