".Touched" Alternative for detecting a player entering an area?

I am attempting to make a door that opens automatically, and then promptly closes when the player leaves the area. This is very easy to achieve with tween service and a remote event. However my problem stems from the method that should be utilized to detect the player being in an area or not. Allow me to further elaborate:

I am quite familiar with some of the current existing methods to detect if “something” is “somewhere”.

First and foremost we have the classic .Touched, which could be matched with .TouchEnded in order to detect when a player enters or leaves the desired part. However this solution has proven itself unreliable, as .Touched and .TouchEnded can trigger multiple times or sometimes never even trigger.

Secondly we have GetPartBoundsInBox(), which is decently reliable, but another problem arises; The server (or client) will have to run that function every second in order to accurately detect if there is anything there, and while I understand that initially this might not have a huge impact in performance, it still seems like a rather clunky solution for a simple proximity door.

And lastly, Raycasts, but a solution for this use case using Raycasts would be way more “hacky” than I’d like a simple door system to be, and therefore I personally find them not suitable for this use case.

What would the ideal solution be for this use case? I have not yet been able to find suitable alternatives.

2 Likes

I think your best bet is the GetPartBoundsInBox()

It would not take that much of an effect on performance, it will be better on performance than ray casting too. And more accurate then Touched

Thank you, I appreciate the reply.
I figure running it every .25 seconds should be fine as long as I’m able to manage and constraint the amount of doors it will be checking every time the function runs. I should also be able to filter out any undesired parts using OverlapParams.

1 Like

It’s a regular for him, he always communicates that way.

But for your problem, I would make everything client side, since its probably only visual. Then just check the distance(magnitude) between the door and the player each frame, if its below a threshold, open the door, if you want it to work server sided so it doesn’t look weird for other players, you can do the same thing, but when a player gets close, fire a remote to the server to open the door instead.

Though .Touched events can work properly, if you just implement a debounce, it’s honestly your choice on how you can handle this, there are countless ways on how to make this.

5 Likes

Communicating like this doesn’t help anybody honestly, tone it down.

parallel luau is absolutely not needed in this case, it is mainly only used for optimisation reasons, so it is definitely not needed for this case.

5 Likes

He does want running GetPartBoundsInBox in a loop, and the fact that it has Write Parallel is like, you know, it would be a wasted opportunity not to use.

I rarely use .Touch and .TouchEnded after learning about spatial queries (GetPartBoundsInBox specifcially), which you seem to have already noted in your post.

Could you perhaps use RunService, and only do the expensive spatial query logic when players are somewhat near the door?
You will have to continuously check players to check if they are close to the door (using while loops in a spawned thread or something), but you could probably get away with a much higher wait time in between checks.

There are also stuff like BlockCast, which is an alternative to a Raycast and would probably work better here.

Unlike what someone has said - Parallel Luau is definitely not needed lol.

1 Like

With your reply it becomes clear; Indeed, constraining the amounts of doors checked based on the distance has proven to be the best solution.
Thank you for the reply, I appreciate your insight.

2 Likes

OP is looking for a .Touched alternative, not solely using GetPartBoundsInBox. But, in my opinion, it is definitely not needed for something like this, as it does not really need optimisation in general.

2 Likes

It’s hard to tell if this is “ragebait”, but given that they said:

Hello i want to remind you that slandering and turning post into harassment is against devforum ToS.
Thanks for attention :handshake:

Given the circumstances I’m willing to believe it is indeed “ragebait”.
Avoiding interaction may actually be the best solution.
Haha get it? “Best solution”. Anyway-

2 Likes

It is.
It’s a runtime loop, so it’s to be considered a hot path instantly.
Furthermore, it does need heavy optimization.

Eleborate.
Did you just made it up or something?

Hopefully im the last one making a comment on this post lol.

Just stop honestly, I mean, you quite started it all, with a rude opening comment:

People would probably respect you more if you spoke more clearly and respectfully, but being mad that you got turned into a laughing stock, because of your own actions I find unreasonable.

It’s your doing, just calm down, we are here to help each other, not hate.

Theres your proof. It’s extremely hypocritical.

Okay, but you shouldn’t be praising someone for basically harassing someone

2 Likes

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