Is there any way I can define
local Hitbox = raycastHitbox:Initialize(model, {player.Character})
in another script and call
Hitbox:HitStart()
in another script?
Is there any way I can define
local Hitbox = raycastHitbox:Initialize(model, {player.Character})
in another script and call
Hitbox:HitStart()
in another script?
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.
How does the RaycastHitbox:DebugMode work?
I donât really understand it
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.
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
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.
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?
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.
Alright thank you for your help.
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.
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
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.
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?
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.
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)
i do multiple hit is taht normal ?
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()
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.
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
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.