Raycast Hitbox 4.01: For all your melee needs!

[Neotrinax (Neo)]

Hi, I have a question. Once you use initialize does the hitbox only create once even if you try to create it multiple times?

[ComplexMetatable]

Just go to mention that the hitbox is extremely accurate!
Thank you so much for this great module.

[ShokuTakahashi (Sho)]

Is there a way to control “How long can a ray last ?” cause if the character is moving so fast it still makes rays behind it that if someone hits the ray he still get damaged even though the caster is far away from him.

[TeamSwordphin]

Hey all, sorry for the long replies! Long story short I had some health complications which ended up with multiple hospital visits. Though everything should be okay now so I should be back to having support here

Anyone with the same questions above who ended up becoming unanswered should repost/reply underneath me so I can take a look at any problems that people are still having.

---

@ShokuTakahashi The rays only draw in one frame, and the positions are based on velocity. I don’t think there is a reliable way to tell time with the way the module works. I think a better solution is to have a range limit so even if you are trailing at light speed, you won’t have a lingering ray in your previous position. Perhaps you can try looking into the MainHandler in the heartbeat loop to see if you can implement this.

@Neotrinax The hitbox only creates once yes. Initialize will always return a pre-existing hitbox that has been created previously.

[ShokuTakahashi (Sho)]

Good that you are okay. I failed trying to make it so maybe i can wait till you can add it in an update for the module. Thats too much advanced for me atm.

[TeamSwordphin]

V.3.3 Stable

New Feature: Did you ever want the hitbox to turn off after a few seconds automatically? Don’t like wait()? Hate using more threads just so your script doesn’t yield? Featuring the new Hitbox Time Scheduler!

Additional information can be found here, though here is a summary from that page for those who don’t want to click onto Github:

Instead of using wait(), spawn(), or delay() which are prone to throttling, consider using RaycastHitbox’s internal custom time scheduler to automatically switch the hitbox off for you. Using this will allow you to continue the script without it yielding. It is extremely simple to use, all you need to do is give HitStart a number. The module will use its preexisting loop to calculate the time automatically with no added performance cost. No hassles and no additional threads created.

local turnOffAfterThisAmountOfSeconds = 5

Hitbox:HitStart(turnOffAfterThisAmountOfSeconds) --- Turns off after 5 seconds automatically

--- Does not yield the thread, the script will automatically continue
print("Hey! I still print!")

Calling HitStop prematurely will automatically cancel the timer as well.

---

Before anyone asks, once PostSimulation is released, I will update this module accordingly to supersede the now deprecated Heartbeat.

[kingschool9 (Mason)]

when will the github have the newest version published

[TeamSwordphin]

Github should now be updated to the recent version

[skeletonmeshupload]

Hello, how do i make the red hitbox thingies not visible?

[TeamSwordphin]

Turn DebugRays to false in the module.

[skeletonmeshupload]

Uhh whats wrong with the hitbox in my game?

robloxapp 20210227 1301396

[TeamSwordphin]

Is the hitbox on the client or the server? If the hitbox is created on the server, follow these suggestions. Similar users working with similar ‘stand’ systems all have the same issues and it seems to be a Roblox replication bug and has nothing to do with the module.

Raycast Hitbox 4.01: For all your melee needs!

Is the hitboxing clientside or serverside? Double check the stand’s position on the server side. A previous user with a similar stand had the same issue as you where the raycasts were not following the animation of the stand when using this module server sided. We found out that the animations and positions doesn’t really replicate properly (still unsure of the source of this problem, either because the stand was a descendant of the player or the player owns the physics of the stand).

Work your way down as I go over some potential fixes.

[Splixent]

Can you add a option to make it so that your Setpoint vectors are static and do not move with the characters animation?

[TeamSwordphin]

Like, make the vectors still follow the originator part but does not take into account its rotation? If I have time I may consider doing it. However, if you are simply asking for a static point in space that will not move, this will be impossible since rays require a distance.

[Splixent]

I drew a little diagram to show you what I mean.

So in this Diagram the blue represents the normal ray, and the red represents the static ray. Normally when a animation plays the ray would follow where the character is looking. With a static ray the ray would still follow where the character is looking, but it would not be effected by a animation. @Swordphin123

[VirtualButFake (Virtual)]

Hey, asking again since it wasn’t answered the first time, @TeamSwordphin, what’s your recommended place to create and detect hitboxes on? (server/client)? I currently have them on the server but I’m unsure if it’d be a better option to put them on the client instead, especially considering latency and other factors that can disrupt the hitboxes.

[TeamSwordphin]

At the time of this module’s creation, I vouched for server-side originally as it came with the biggest convenience with the added benefit of added security. However, as I grew and improved as a developer, I came to the realization that UX and player feedback should be the most important aspects of any game. If your game feels “responsive” with it server-sided already, I see no reason for it to change. The most important part is if it feels fine to the end-user. Though, if you are still early in development, I would recommend putting them on the client for the best user experience. Hitbox accuracy also substantially improves on the client as frame rates are much more consistent than replication.

An example of how much smoother client hitboxes is compared to servers can be seen here, and I had an extended opinion on why I think client-side is better as well.

Raycast Hitbox 4.01: For all your melee needs!

If the server is lagging, that will be its longest delay. The module uses Heartbeat, so it will check for collision between frames. If there is lag, Heartbeat will stall and update less often, which will in turn also make OnHit not as accurate. Handling anything server sided is choppy because replication runs at around 15 - 20hz (versus the buttery smooth 60hz on the client). If smoothness is the priority, I would opt to run the knife throw on the client side and have other clients replicate th…

I feel a lot of developers are also afraid of implementing client-side hitboxes due to the potential security and exploits that comes with it but with the proper server verification checks, it can be as bullet proof as if the hitbox was originally on the server-side. I gave some examples to previous users which can be located here if you are interested

Raycast Hitbox 4.01: For all your melee needs!

An example of basic sanity check is: make the client do all the hit detection with this module. Once the client hits a humanoid, send a remote event to the server essentially telling the server to damage this humanoid it hit. The server won’t immediately damage the humanoid. Instead, it will verify first if it is valid. A simple way is to do a raycast between the hit humanoid and the player that called the remote event. If there is a wall between them, don’t damage the humanoid (because you’re …

Raycast Hitbox 4.01: For all your melee needs!

Yeah, preferably everything on the clients (includes hitstart/stop). Then you can tell other clients to draw the projectile on their screen too. It won’t be as vulnerable if you do proper sanity checks, it’s just a bit more work but the payoff is worth it. One easy sanity check is to make sure if the client tells the server they hit the target, don’t trust them, instead do a raycast between the aggressor and the hit target to ensure that nothing is between them. You can also do a magnitude chec…

[VirtualButFake (Virtual)]

In that case, would you say that dot product & magnitude checks are sufficient for security or do you have any suggestions for other security methods?

[skywildsaturn (DaabocJr)]

Yo man, I’ve tried adding an ungodly amount of attachments to the swords in my game, and the hitbox is still facing reliability issues. It basically only happens when the character is standing still. If you jimmy the camera a bit when you swing(there’s mouselock in my game so that rotates the character), it works perfectly.

I’m running the hitboxes on the client, but the attachments are created on the server. Any clue what’s going on?

(I tried giving one of the swords 200+ attachments and that still did not solve reliability issues.)

[TeamSwordphin]

@VirtualButFake Dot Product + Magnitude is a good start, and may even be enough depending on what your game is. I would combine it with raycasts as well if you care at all about the player/enemy hitting through walls. It’s difficult to really “recommend” security methods, since it depends on what your game is and what makes sense in your game. If you can describe what your game is about for me, I’ll be more than happy to give some tailored security suggestions afterwards.

---

@skywildsaturn Unfortunately, this is the nature of raycasts in general. If you are standing still, there is not enough distance for the rays to detect anything. In addition, rays cast from inside a part will not register a hit, only when the ray is cast from outside a part will it detect a hit. When you are standing still with your sword inside the target, the rays are being cast from the inside. I believe this is a problem in other game engines as well, like Unity. This is not just a Roblox problem.

Here are some examples of what I’m talking about.

Summary

Let’s take this image for example.

Gray brick: This is our target
Blue brick: This is where our rays start casting from, or in RaycastHitbox’s case, the attachment position
Red brick: This is the direction the ray is casting to. Of course, the distance is a bit exaggerated but it’s basically how the module works.

When the start point blue brick is inside a part (the gray brick), and starts casting a ray, it will not register a hit. I’m not sure why it doesn’t, but it’s probably for performance reasons with mesh occlusion.

If we move the Start point outside of the target, our rays will now start detecting hits.

This is the same reliability issue you are experiencing but on a much, much smaller scale. If you are unmoving, and your raycast points are inside the target, the raycasts will never detect anything. Unless Roblox designs another type of raycast system that ignores occlusion culling, this is unfortunately not possible to fix (or at least, in a way that doesn’t require much work). This module has a LinkAttachment feature that you can try in combination with your current attachment setup. It basically draws a ray between two points, and it may work for what you are trying to accomplish. Have a point on the handle, and then the other at the tip, and if your target isn’t too big, your hit detection should be better while standing still.

Due to the nature of this module, even if you are standing still and your target comes towards you, it may not guarantee a hit since the rays in this module requires distance and velocity (hence why it works when you swing). Adding a minimum raycast distance as well won’t work either since the above reliability issue will make that change meaningless.