Touch and TouchEnded is NOT INTENDED for the creation of enter/leave zones

I’ve been working on a toolkit for something.

Similar to ZonePlus v3.2.0 | Construct dynamic zones and effectively determine players and parts within their boundaries

 

I was trying to test a lot of things trying to find the best solution possible. And I made a realization that I’d like to share.

So, my first approach was to utilize Touch and TouchEnded, just to test.

 
And the first discovery was that, TouchEnded would fire everytime while I jump inside a part that I am still inside at.
 

So I made a realization. There’s a function for the Class BasePart called GetTouchingParts.

If I’d single fire that function while I am in a Part, it would return something empty.

So I started to make a realization.

Which was that Touch, is if you Touch a Part, and nothing else.

This means that Touch is intended for touch detection ONLY, and nothing else.
And with that I mean only the borders of a Part. Anything that has to do with Touch.

I think that’s what Touch and TouchEnded are intended for, and using them for any kind of Zone detection, is a bad approach from my perspective.

Touch detection, straightforward is if you touch a part. And not if you’ve left or entered an invisible zone.

This is why any touch related function, will give you these strange results. And that’s because they’re not intended for the purpose of zone detection.

 

A better function would be GetPartsInPart. I had an issue with GetPartBoundsInBox, because it would include the Baseplate as well. Maybe I have to remove like 0.001 of every side of the .Size parameter. But, yeah.

BoundingBox detection would be the better approach. As you then also do not have to rely on CanQuery anymore and then it wouldn’t mess with Raycast.

 
 

Though just a word in general. You might have tried to detect the player and realized that it’s still glitchy. In most games, the player model is just a model. A mesh. That comes with one single hullbox as the AABB, which is useful to implement any kind of crouch and etc. features.

A Roblox Player Character by default, has more than one hitbox. Basically, that what is supposed to be the player model, are a bunch of BasePart hitboxes.

R15, has 15 Parts. And if you’re having a jump platform and jump up, sometimes you trigger leave, but also trigger enter again, and that’s because one of those 15 parts entered again.

If you’d want to have a more clearer zone detection performance wise. Then I believe detecting just one box would be a good approach.
 

However…

Have you ever tried to just remove CanCollide from all of the parts?

It works, along with HumanoidRootPart, however. As soon as you jump, the UpperTorso and the LowerTorso gets their CanCollide set back to “true”… While I think they always have it set to true, but :person_shrugging:

so… there’s that…

Having a script that just sets it back to false, is not a solution. Because it gets set to “true” already and that means the impact is already done. Any Changed and etc. listeners would trigger.

Plus, if you’d be doing it your character would fall…
Otherwise CollisionGroups are the only solution to implement a custom hull box and disable the entire collision of the player parts. But same thing with falling applies.

Using the HumanoidRootPart for the hullbox, is bad. If you scale that thing it changes your movement and any sort of workaround like speed change, just for that, is bad as well.

If you disable all the collisions, your character falls down the world. So one of the parts is still responsible for proper movement. For some reason if you do it manually sorta, it doesn’t.

Eitherways, hope this thread was helpful in any sort of way.

6 Likes