Isn’t this true for anything else or is it specific to GetTouchingParts and Touched? Are there any release notes hinting towards this? Personally, I don’t use :GetTouchingParts() but it’s good to know it’s an option, I know a fair bit of users that utilize GetTouchingParts (The only good thing about this is that you have more control of the shape of your hitbox).
2 Likes
I’m unsure - you’d have to look it up yourself. I’ve never seen any references, only users abusing this hidden feature to get GetTouchingParts working on cancollide off parts. There’s nothing on the wiki about it, and from my years of being on devforum I haven’t seen much official talk about it either.
3 Likes
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
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.
3 Likes
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
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
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.
3 Likes
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
Here’s a decent enough result I got from the same raycast from multiple points method
(Contains blood)
4 Likes
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
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
3 Likes
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?
I’m… unsure what your point is.
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?
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.
Sorry to necropost, but I wanted to correct something:
This can be patched using this simple workaround
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’.
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.
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.
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)