Raycast Hitbox 4.01: For all your melee needs!

[kingschool9 (Mason)]

when will the github have the newest version published

[TeamSwordphin (Phin)]

Github should now be updated to the recent version

[skeletonmeshupload]

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

[TeamSwordphin (Phin)]

Turn DebugRays to false in the module.

[skeletonmeshupload]

Uhh whats wrong with the hitbox in my game?

robloxapp 20210227 1301396

[TeamSwordphin (Phin)]

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 (Phin)]

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 (Phin)]

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]

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 (Phin)]

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

[DiehvcTy]

Should I :Initialize() on a “attacking” event? and then :Deinitialize() when its completed, or should I :Initialize() when the player’s character is added, then do :HitStart() and :HitStop() when the event is called?

[TeamSwordphin (Phin)]

The latter. Spamming Initialize or Deinitialize will affect performance. Only do them when you create the hitbox/no longer need them. Treat them like instancing or destroying and you will be set.

[ncs03082 (Wooloo)]

Hey I think something might be wrong with the code with the initialize function. I’ve set it up the same way you did on github but the error still appears. I checked the modules code and I’ve noticed that the first line under the initialize function has an error.

ps. Sorry if I didn’t format it correctly This is only my first post on the forum

[TeamSwordphin (Phin)]

The github formatting is slightly wrong due to me not being able to put descendants like you can do with studio. In the future i will convert it to rojo compatible to make it easier to import to projects.

Make sure all the contents of raycast-src is under RaycastHitbox.lua.

• RaycastHitbox.lua
• • CastLogics
• • Tools
• • MainHandler.lua
• • HitboxObject.lua

If it still errors with this formatting, let me know.

[BL0XELS]

This is perfect! I feel bad for using this even if it is community resource so I donated too. Hope its enough!
Keep up the hard work dude!

[sonicvsmaio4 (Trigorojo)]

EDIT: I’m using v3.2, since I just returned to this from earlier February. Will update soon enough.

Hey Swordphin! I am making a fighting game with various martial arts, and I came across two issues while making a boxing tools with set-points using the actual left/right arms of the character.
I will demonstrate the left arm only since the right arm is a copy and a near-duplicate of the left.

I apologize if I have overlooked anything, and I consider your work to be magnificent.

I would post code blocks but I don’t know how, and I apologize.

-I have tried RemovePoints()
-I have tried turning DebugMode off on unequip, and on during equip

Sorry if I don’t explain it clearly but, I feel like my code might need to be improved on since when setting new set-points with c["Left Arm] then the following:

• positive and negative version of c[“Left Arm”].Position.X/2 in the X position of the first pair of Vector3s
• +/- versions of c[“Left Arm”].Position.Y/2 in the Y position of the second pair of Vector3s
• +/- versions of c[“Left Arm”].Position.Z/2 in the Z position of the third pair Vector3s

This is the first issue that arises:

• Relative to the person’s left arm’s position in the initial spawn position without a spawn location,
  the set-points seems to work for Y although it floats off the actual object (which is neither good or bad), and the set-points works for one of the other vectors (not sure if it’s X or Z, it seems to be X that works based off the 3d-space cube with the axises, but it could be Z) but not both of the horizontal axises.

-Gyazo link- One of the axises are missing on left arm, ignore the right arm.
For illustration, the above picture [at ZERO,ZERO] added four new -Y vector3s with added +/- Xs in the X part in the new first pair, and +/- Zs in the Z part in the second pair. Intentionally there should be a dotted cross formation there, but all there is is a dot stream to the left and right of the arm, but not to the front or back of it. The -Ys were graphed in their intentional place, while one of the other horizontal axises were as well but not both.

This is the second issue that arises:
When the character re-equips his tool anywhere away from the initial spawn, any distance, something scales the set-points and their debug trails further away from my arm.

I assume that the area where the drift from the arm is minimal is the “ZERO,ZERO” of this emergent scaling.

I tested with and without a spawn location to see if ZERO,ZERO changed. it did not. The initial spawn without the spawn location seems to be the only area where set-point drift is at its minimal.

-Gyazo link- ZERO,ZERO streams close to body at 1st activation, new streams far away from 2nd activation some studs away from ZERO,ZERO…

I would have a question about why the gap between the set-point and the axis.Position/2 exists at all,
but if the second issue did not exist, I would just scale it using a number higher than two to reduce the gap, and all that would remain is why one of the horizontal axises didn’t translate properly.

Thank you for reading, and I thank you for being helpful as much as you’ve been.