Raycast Hitbox 4.01: For all your melee needs!

Is there any way I can define

local Hitbox = raycastHitbox:Initialize(model, {player.Character})

in another script and call

Hitbox:HitStart()

in another script?

6 Likes

Untested as i dont work with modules all too often, but try to initialize in one script, and then in the other script, require the same raycast module, and then use

local Hitbox = RaycastModule:GetHitbox(your instance here)

If its not nil, you can use hitstart on it. If its nil, then I can try to make it work in a future update.

5 Likes

How does the RaycastHitbox:DebugMode work?
I don’t really understand it

3 Likes

Refer to the bottom of this post:

DebugMode is intended to show the raycasts being performed on the hitbox so you can see how your hitbox is interacting with the world. It helps you tailor your hitboxes better in regards to sizing, placement of nodes and anything in regards to fixing or testing your hitboxes.

2 Likes

Swordphin123 has added a line that can enable or disable the debugmode inside a script
That is what i don’t know how it works

1 Like

Its a simple boolean on off switch

RaycastModule:DebugMode(true) --turns on rays
wait(5)
RaycastModule:DebugMode(false) ---how quaint, somehow this turns it off!

Hope that helps.

8 Likes

Does this have to be used in the same script as the script that makes the hitbox?

And is it possible to set it true via a localscript inside a gui?

1 Like

I haven’t tested it with another script, so preferably it should be used in the same hitbox script.

But you can try to require the same module in your gui script and then see if DebugMode works in there. The RaycastModule will have to be client sided then for it to work.

If that doesnt work, you most likely have to use a bindableevent or remoteevent depending on your needs.

5 Likes

Alright thank you for your help.

3 Likes

I don’t know if a feature like this has already been suggested but it would be nice if you could add a feature where rays are created in between two attachments.

For example, if I had 2 attachments on a sword and 1 attachment was on top and the other attachment was on the bottom of the sword, there would be rays created in between those two attachments with a variable that could decide how far each ray would be apart.

This is a great module nonetheless and I’m planning to implement it into one of my upcoming games.

6 Likes

Hello,

I’m quite new to raycasting, so I’ve got a question (I haven’t seen this asked before). Do I need to put this script in a local script and then use a remote event to damage or do I cast the rays server side?

Thanks for your help,

Kees

1 Like

It’s personal preference. Put it on server side if you desire more security but less responsive gameplay, or put it on client side to have the ability to gain instant feedback (and make your combat feel a lot more snappier) in turn for more security checks (and generally a bit more work, using remote events, distance checks, angles, etc).

If you use the damage arguments instead of the OnHit connection line built into this module, then you will have to use it server sided.

7 Likes

Since the hit method is determined by casting a ray from the current attachment position to the previous one every frame, how would you safely do a distance check for that on the server?

4 Likes

Just a distance check probably won’t be enough, assuming you are using this client sided, and are using a remote event to tell the server “Hey, I damaged this enemy”. A potential exploiter can simply just call an entire different target across the map, and when the server receives this input from the clients, it should always check distance, be it magnitude or regions.

Recognize common sense in your game, such as an enemy should never be damaged 50 studs away if your swords are only 5 studs in length.

You can also combine distance check with angle checks. For example, to make sure you aren’t actually damaging someone close to you but directly below you.


These checks aren’t necessary if your hit methods are already all server sided and if that’s the case, efforts should be made to optimize it instead so your players can get the best responsiveness out of it. There can also be some potential exploits even on the server side, mostly teleportation or position based, so you should check for velocity or position differences here on top of any other checks.

8 Likes

Hello again,

I have implemented your hitbox module. I have done it for a sword and for a punch tool. The sword works fine, thank you, however the fists don’t seem to work good. They work for me, if I hit players in game I deal damage, but others players aren’t dealing any damage to anyone. This is very similar to a question I asked a week ago about touched events. Partly because that didn’t work I decided to try Raycasting, but now that doesn’t work for the punch tool again. When I enable debugmode then only my punch tool has red rays, others dont (I handle it server side), Below here is my script, only “Click” prints, and in the module script only “Created Hitbox for Object” prints. Maybe you can help me?
Kees

local tool = script.Parent
local player = tool.Parent.Parent
local character = player.Character or player.CharacterAdded:Wait()
local rightHandBox = Instance.new("Attachment",character.RightHand)
rightHandBox.Name = "DmgPoint"
local leftHandBox = Instance.new("Attachment",character.LeftHand)
leftHandBox.Name = "DmgPoint"


local RaycastHitboxModule = game.ServerScriptService.RaycastHitboxModule
local RaycastHitbox = require(RaycastHitboxModule)

local Damage = 10
local hitTime = 0.5 -- the time between each hit


local NewHitbox = RaycastHitbox:Initialize(character, {character})
NewHitbox.OnHit:Connect(function(hit, humanoid)
     --- Do not put events on a loop, else you will memory leak and it will damage multiple times!!
     print(hit.Parent.Name)
     humanoid:TakeDamage(Damage)
end)

tool.Activated:Connect(function()
	print("Click")
	NewHitbox:HitStart()
	wait(hitTime)
	NewHitbox:HitStop()
end)
6 Likes

i do multiple hit is taht normal ?

1 Like

You could try using _G or shared

-- script one
local Hitbox = raycastHitbox:Initialize(model, {player.Character})
_G.go = function()
Hitbox:HitStart()
end
-- script two
_G.go()
2 Likes

You can use ModuleScripts to get references to custom objects between scripts. Using the global environment for this is quite bad because it makes your code very hard to understand. I recommend not using _G nor shared at all in your code bases if you can – you don’t actually need it.

3 Likes

I for one think it makes your code quite a bit easier to understand.
If it’s not meant to be used, why is it there?

It’s super convenient

2 Likes

It was put in far before module scripts were. While _G and shared are not officially deprecated/removed, it’s still advised to use module scripts rather than storing everything in a shared table like that. Easier for other programmers to read a code base like this too if you collaborate. Since they can see the hierarchical tree structure of your code base.

Roblox doesn’t like to always remove features that are no longer necessary because by doing so they could inadvertently break a lot of games which still happen to rely on it.

8 Likes