Best way to replicate the .Touched feel with Raycast?

Help and Feedback Scripting Support
1

Basically, I’m recoding an old sword tool for a community to transfer over from .Touched as it’s very vulnerable securitywise.

Obviously, Raycast is more responsive which can cause more registered hits and damage compared to .Touched. Does anyone have an idea what approach I could take to minimize the difference in that sense and make it have the same/similar feel?

I did have an idea of running an additional .Touched event on the server to register damage based on the amount it’s recognized serverside and ignore additional extra damage checks that came from Raycast, but it may miss out on crucial hits with that + it would still be vulnerable with .Touched.

Any ideas really do come in help. Thank you!

1 Like
2

I wouldn’t use Raycasts for traditional hitboxes, you should look into using spatial querying APIs like WorldRoot:GetPartsInPart() if you want a replacement for Touched.

If you’re looking for something else, I might know a few other APIs that can achieve what you want!

3

That can work as well; I did word myself a bit wrong there, sorry about that.

However, it would still be some sort of a looped check - compared to .Touched, it would most likely register hits way more often and cause a significant increase in damage.

I need some ideas or a solution on how the feel could be replicated to be as similar as possible.

4

You can have a filter list, excluding or including certain parts.

5

Yes - however, this is a player-to-player combat based tool. A looped check (it’s necessary regardless) will constantly check for collisions and inflict extra damage, compared to what .Touch usually feels like.

So I need some ideas on how this could be replicated to have the same feel. Of course, any ideas come in help or if anyone has already experienced a situation of this sort.

6

workspace:BlockCast can help you in this.

7

Well you can exclude parts once they’ve been hit until you want to be able to hit them again.

8

That’d be more for guns and ranged weapons, not quite what OP is looking for.

9

Yes, but think of it as a classic Sword tool. That constantly goes into the character - it’s not a basic combat sword from anime games that works on 1-hit actions. This would be perfect otherwise.

Yes, and thank you for that, but my question stands as this - it’s not about how the detection could be handled, I’m looking for ideas how the detection itself could have a feel of a .Touched event as similar as possible.

10

So if I understand you correctly, you want it to be able to hit the part again after it stops overlapping the part?

11

Somewhat, yeah. With what you just mentioned, I may have gotten an idea on what could help in that case.

But then again, with that, collisions are usually also detected while in overlap mode. So this would still take power away from the tool.

12

Should be as simple as just checking if the part was overlapping during the last check, if it wasn’t you can count that as a hit.

13

What makes you say that?

A sword in its basic form has a hitbox, If someone were to use a BlockCast for swords, they would cast a ray from the last position to the current position of the sword’s hitbox; it would work the same way.

I don’t understand how “for guns and ranged weapons” is appropriate for BlockCast. RayCast is more appropriate for guns and ranged weapons, not BlockCast.

Then just use .Touched? Realistically, there is no alternative to .Touched that has “the same feel as .Touched” unless I’m misunderstanding your question.

Can you explain a bit more about what you mean by “the same feel as .Touched”?

14

A BlockCast is a Raycast, but with a block.

Raycasts aren’t meant for melee collision checks, they don’t hit parts if the origin is within that part.

A blockcast can be appropriate if the projectile is something large, like a missile.

15

Basically, .Touched can be manipulated by the client as of late. I’ve made bug reports, tried various fixes (firstly Raycast which was dumb (i worded the thread a bit wrong), then Blockcast, then Shape cast, etc.), and basically nobody cares about it. This is a wielded tool that is held by a player.

With that, they can alter CanTouch on their characters to negate incoming damage or exploit .Touched manually. In that case, I tried Magnitude, but they can manually fire .Touched at any time - this causes multiple detections for extra damage.

That’s why I need an alternative way of how a .Touched could be replicated. There’s genuinely no way a developer out there didn’t try some sort of a route to fix this, especially considering there are a lot of sword-based games out there.

maybe i should just give up ig lol

16

Of course Touched can be manipulated by the client, they own the parts so they have control over them.

You can implement server-side distance checks (this is the preferred method, still allows the client to have authority over determining hits, preventing “unregistered” hits when the client is desynchronized).

17

so there’s really no point in it

18

Can’t really get around them firing .Touched at any time, because how can you differentiate between someone flicking their camera to register multiple hits, and an exploiter doing the exact same thing minus the flicking?

You can implement debounces along with the magnitude checks, you just have to balance the tradeoff for normal players.

19

If you say that then I’m sure that the many melee systems currently in use are fully faulty and should be changed immediately?

Using :GetPartsInPart also has many issues, for example, any frame drop or if the animation was to jump too fast, it would completely skip over a part. This issue doesn’t occur with raycasts.

As for:

This is extremely unlikely to happen as the rays are casted every frame and there is bound to be atleast one frame in which the object would be properly detected.

If your issue is extra damage then just put all the rigs to damage in a table and apply the damage later on?

20

I don’t think that’s possible, the client that has ownership over the tool should be the one determining whether the parts have touched.