Melee Hitboxes - What Is The Best Solution, and is the Touched event really that bad?

Resources Community Tutorials
#8

Raycasting is fine for hit detection. Raycasting from multiple points. This is how games like Mordhau and Chivalry do their hit detection.

For general collision detection that needs accurate physics(not just orientated bounding boxes), GetTouchingParts is your best bet for reliability. TouchEnded doesn’t always fire so using it to keep track of collisions is not great.

I personally wouldn’t GetTouchingParts just for hit detection for a sword or something though, since again raycasts are more suited and less costly for the task.

3 Likes
#9

Are you referring to my solution to the problem? I’ve proposed using Touched; I’m assuming you’re talking to Mystifine.
Raycasting isn’t bad and is very useful in some situations; the issue with it would be that it scales horribly, and as stated has ping issues if you don’t handle it properly. It’s also O(n) in terms of number of parts in the workspace (even though its a very low n) - I’ve benchmarked it to confirm this previously.

2 Likes
#10

I was just chiming in on the topic as a whole , I didn’t really read in depth about everything that was being discussed.

Ping issues seem like more of a fault in however you’re handling your netcode/a game design fault rather than raycasts problems

3 Likes
#11

Speaking of the raycasting method, I remember a module that was made for specifically melee weapons:

Oh looks like I overlooked the dropdown details.

2 Likes
#12

I’ve taken that module into account and used it in the theory part of the thread, showing an example of a good hitbox module that utilizes raycasting.

2 Likes
#13

Yeah all that does is raycast from multiple points, same thing that games like mordhau do. Pretty easy way to get decent hit detection working for objects like swords

3 Likes
#14

Here’s a decent enough result I got from the same raycast from multiple points method
(Contains blood)
https://streamable.com/mgqr8

4 Likes
#15

I still believe that Touched is a better alternative if you’re looking for efficiency; as it’s handled by Roblox’s engine, it’s bound to be more efficient than an O(n) solution which is constantly fired up to 10 times every frame, per weapon.
Regarding the ping, yeah I didn’t mean raycasting in specific. Taking ping into account with raycasting is slightly more complex (if you’re going to be smart about it), as it requires good client-server communication. Touched already takes all of this into account internally as all collision calculations are handled on client, and I’ve reasons to believe the ping would be (even if very slightly) faster, as it’s connected towards the server internally, without any remoteevents being used as “proxies” to forward it.

1 Like
#16

Big issue with touched is usually for games like this (like the video I linked - a chivalry inspired game) , you really need the information that rays provide such as the actual point of impact. Touched doesn’t give you this. Not only for effects but also for cases like mine where I had to detect if the impact point of a blade’s raycast result was within my parry box, to evaluate whether or not it was a parried attack or a successful hit.

If roblox passed in the point of impact on Touched that’d be much more useful - but that’s unlikely going to happen

2 Likes
#17

Sorry if real late reply…

So I like your idea, you’re right touched can be absolutely horrid for exploits… the way you handled it is decent.

But let’s talk about magnitude… assuming you used magnitude client based… One thing we know is client can be seen by practically anyone and that’s bad because about 70% of people who use injectors know a decent amount of lua. Magnitude in my opinion is a very basic level of understanding and with that they then can take steps of making ownership theirs starting with adjusting magnitude. Now like I said assuming magnitude is client also must mean damage is client which personally does not make sense if you want damage to well… do damage. (Correct me if im wrong in rusty and havent touched studio for about 8 months)Humanoid is a property of a players character(meaning it contains everything that your player has like body parts, hat’s items, etc.) HUMANOID is in the character. So it would be better to handle hit boxes and damage server sided prevents a lot of headaches. FE and letting the server take control of what it should, should prevent bug central.

Like I said correct me if im wrong. Even though I’m pretty sure I thought of it all… Maybe?

#18

I’m… unsure what your point is.

#19

Well, if your game is fe, a client will not be able to do things like put stuff in workspace or edit it, at least not what ALL players can see. So if damage is client based a hacker can think he’s really killing players but, they are really just walking around wondering why is this weird guy just running into me. Do you get what I mean now?

#20

If you’re talking about how Touched is bad because it’s client-based (I still don’t understand your point really) and thus has to take into account for magnitude (which it doesn’t collisions are calculated way differently), then your point would be flawed. A lot of games have to take into account for the player ping and position at the end of the day. Yes, it is spoofable, but the difference wouldn’t even be that big at the end of the day, otherwise you’d see exploits where you could kill people across the map on games like Fortnite etc. The same meaning would apply in this case.

#21

Sorry to necropost, but I wanted to correct something:

This can be patched using this simple workaround

#22

It’s not a ‘patch’ - it’s a band-aid solution that’s still exploitable at the end of the day. Exploiters can simply delete TouchInrerest objects the moment they appear, or even yet introduce special methods to not send that information to the server,m - as such I didn’t mention that ‘fix’.

#23

Assuming you are either calling GetTouchingParts on something from the server, or from the client that wants to make hits, I don’t see how an exploiter removing TouchInterest or withholding items from being returned in GetTouchingParts called from their own client would make sense for them. They’d just be denying themselves hits, presuming each client calculates its own hits and the server does some validation on that.

My understanding is GetTouchingParts doesn’t require a TouchInterest in the other part, only in the part you are calling GetTouchingParts on, and if you call it instantly after connecting a Touched handler there is simply no networking involved, it’s purely detecting touches in that single frame on that network node.

#24

I’m no expert on the matter so I can’t really go into detail on what actually goes on, but I believe you’d agree with me on the fact that it still is a band-aid fix.

#25

It’s simply not related to security/exploiting – all that adding a TouchInterest does is making it so non-cancollide parts are picked up by the GetTouchingParts computation. The previous post of yours implied it was related to security, which is what I was responding to.

The band-aid is that you need to add a TouchInterest to get the function to act differently, not that it somehow compromises security more (or less) than if you did not do that. The security model is the same. (don’t trust physics asserted by clients)

#26

In the context of security, I agree, yes. But with how Roblox has been recently, I’d rather not mention solutions that are less steadfast - for instance, with deferred behavior; even though its arguable on whether relying on instant event feedback was weird or not, I still did not rely on such behavior nevertheless because I had a hunch the behavior would change one day or another (which, I was correct on). I remember arguing with people on this matter, though that’s on a now-deleted account so I can’t provide much proof regarding it.

A much better solution to the band-aid Touched fix would be to instead use the newer solution that Roblox is working on, which is meant to supersede Region3 (MaximumADHD’s log showed these being worked on). I’ll likely update this thread once those come out.

#27

I think you’re missing the point or trying to pull of a red herring fallacy here. Let’s go back to the original point you made that I responded to. The “much better” new solution you point out will have the same weakness you pointed out before: just like an exploiter can delete the TouchInterest to manipulate GetTouchingParts results, an exploiter can also manipulate the results of whatever new API Roblox releases for hit detection, by withholding parts returned from such API calls, if done on their client. (they are in full control of their client)

Again, the point here is that you cannot trust physics assertions made by a client. There is no magic API Roblox can release to fix this, and it has nothing to do with the hackiness of adding a TouchInterest to GetTouchingParts.

If you want security, you need to validate assertions made by the client on the server. There is no silver bullet for this problem.

3 Likes