Why does altering a part fire a touch event for every part in the model

Help and Feedback Scripting Support
1

I have a sequence of problems and would appreciate any suggestion.

I’m having an issue where every time I change a part’s property (such as its CanTouch value or its size) it fires touched and touchended events for every other part in the model.

Here’s a video of me changing the CanTouch value of one part and it causes touchended/touched to fire for the glowing white square under the water (which is not the part I’m editing), causing it to act as if just rapidly untouched and retouched the water that it is already overlapping with. This is awful, causes so many problems and I have no idea why it would be like this.

I have to change the CanTouch value of the part because .Touched event won’t fire for a part which was already touched and has not stopped touching, even if the Touched event was disconnected during that time.

What I mean by that is, every time the player attacks the .Touched event is connected to their attack volume and disconnected when the volume is no longer dealing damage. It would use unnecessary resources to keep these connected at all times so the’re only connected when attacking. However, when this happens the .Touched event will not fire for an overlapping part that was previously touched unless they untouch and touch again. This causes hit registration problems if players are standing still.


I can get around this issue by turning .CanTouch for the attack volume off and back on before attaching the .Touched event… but then that causes the first problem, in which every other part in the model with a touched event attached behaves as if it just untouched and retouched everything they were already overlapping.

The only options I can think of are:

  • Do a :GetTouchingParts operation or something similar for the Attack volume when attack is fired to register any parts that are already touching it (afraid of the server resources this would use)

  • Keep .Touched and .TouchEnded events always or almost always connected on the attack volume to constantly keep track of what it’s currently touching (afraid of the server resources this would use + terrified of how complicated this would make adding additional attack types in the future)

  • Have the client double-check touch events if they have recently attacked by using :GetTouchingParts or something similar (afraid of the client resources this would use, seems like a very hacky getaround, doesn’t always work from when I tried it, doesn’t address other things that could possibly cause this in the future)

  • Accept awful hit registration problems that occur when players attack while not moving

Things that didn’t work:

  • Un-attaching the attack volume from the model in the hopes that this wouldn’t cause the first problem to happen (first problem still happens)

  • Instead of changing the CanTouch property, changing the attack volume’s size and then resetting it to cause it to re-overlap with parts (first problem still happens)

  • Create a fake attack volume part that mimics the player’s actual attack volume, attach it to their attack volume, register .touched events on this part instead and then destroy it after (the act of welding it to the attack volume causes the first problem)

anyway these problems are very strange and are driving me absolutely insane. id appreciate any suggestions

2

This is simply how touched events work. Assuming you didn’t write checks in the code to stop it from running code from parts in the model, the touched event will fire from a touch of any part.

3

Connecting and disconnecting your .Touched events as needed is the way to go. To deal with objects that are already hitting the hitbox when the attack begins, try WorldRoot:GetPartsInPart(). It’s a more modern spatial query method and less fiddly than BasePart:GetTouchingParts().

As far as the performance of determining initial intersections, the cost of either function is negligible within the scope of what’s happening. Neither should have a meaningful impact on the game unless they’re being called hundreds of times per frame, and the value to players of having snappy, responsive hitboxes cannot be understated.

1 Like
4

The parts that are causing problems by firing touch events when they shouldn’t aren’t touching the part that is being altered. Changing the properties of a random part in the model causes Touched/TouchEnded event to fire instantaneously for other parts in the model, causing them to act as if they just rapidly untouched and retouched parts that they were currently touching, which aren’t the part that was being altered and arent part of the model, which doesn’t make sense

5

Thank u, Ive generally read that :GetPartsInPart and functions like that are laggier than just using .Touched events so Ive been cautious of relying on them

6

Yeah, I wouldn’t use them as your sole means of hit detection, but they aren’t bad. I’ve used cones with :GetPartsInParts() in place of huge swathes of raycasts in places where I didn’t need to know the exact hit position and improved performance by a huge margin.

1 Like
7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.