If ALL Players Are Touching The Part

you are looping every 3 seconds, finding a player and adding it to the table, if the player decides to stay in the region, he will be added to the table again…

local playerList = players:GetPlayers()
local playersInRegion  = {}

I think you missed these 2 lines of code.

you are looping for each part that is touching the region…

if it finds HEAD and finds HUMANOIDROOTPART then for 1 player there will be 2 players in every array… do you understand?

if v.Parent:FindFirstChild("HumanoidRootPart") and v.Name == "Head"

Please learn how to read others code before commenting, thanks.

Don’t use Touched/TouchEnded events to handle this, they are awkward and often fire even when they shouldn’t due to the nature in which the event describes parts touching other parts.

region3 has alredy been depracated, touch is not.

Region3 is a lot more reliable for this kind of tracking than Touched/TouchEnded, regardless of deprecation status.

All of these answers are completely wrong.

You should use BasePart : GetTouchingParts method to get a table of all the parts touching, store each unique player in a table and compare it to the amount of players in the game.

https://developer.roblox.com/en-us/api-reference/function/BasePart/GetTouchingParts

3 Likes

I agree with this method completely. There’s still a lot of ways to go about using :GetTouchingParts() in this situation, though.

The method you should use depends on how frequent you need to check for when the players are all touching the part.

If you need to know as soon as possible, then the best option is to use :GetTouchingParts() in conjunction with the Touched event. I believe you would need to do this anyways if the part is non-cancollide to ensure detection, but you would need to actually write code for the event in this case.

If you don’t need to know immediately but would still like to know somewhat often, say every 0.5 seconds, then it would likely be more efficient to use a loop that runs a :GetTouchingParts() loop every 0.5 seconds.

1 Like

Exactly, but it’s safe to say that the obvious way to go here is by BasePart : GetTouchingParts.

Region3 is absolutely awful and Touched on just its own doesn’t really mean to serve the purpose of this question.

  • Create a Touched event

  • Have a function return true or false using the BasePart : GetTouchingParts to check which players are touching (By creating a table, inserting each unique player into the table and comparing it to the amount of players)

  • Have a loop run and check if the function returns true or false every x seconds

1 Like

GetTouchingParts() is built off the back of .Touched which in and of itself is a clunky event which regularly misfires, Region3 is the way to go, regardless of the fact that it has been deprecated.

I must add it’s funny how you didn’t even attempt to provide your own solution, just some generic documentation page link with little to no opinionated reasoning whatsoever. You were quick to discount other solutions without even the slightest of explanations as to why.

You clearly don’t understand the point of the Touched event here, it’s not being used other than to create a TouchInterest so that GetTouchingParts can fire.

BasePart : GetTouchingParts is reliable and if it isn’t, you’re using it wrong. You’re recommending that they use Region3 which is not only deprecated, but causes lag and is way more unreliable.

I find it funny how I did provide an algorithm in my 2nd message but you decided to ignore it. I’m sure an algorithm with the correct methods is more compelling than a piece of deprecated and unreliable code.

2 Likes

I’m also going to note that BasePart : GetTouchingParts has nothing to do with a .Touched event

We’re only using it so access the TouchTransmitter, so the event is actually empty and its ‘unreliability’ which only stems from people’s mistakes has no context here.

2 Likes

We’re only using it so access the TouchTransmitter

Saw this immediately, stopped reading right then and there.
Thanks for the wall of text though, will make for a good copypasta.

I must add it’s funny how you didn’t even attempt to provide your own solution, just some generic documentation page link with little to no opinionated reasoning whatsoever. You were quick to discount other solutions without even the slightest of explanations as to why.

3 Likes

I’m not sure if this is a troll account, but I’m going to give you the benefit of the doubt and explain a few things to get the perspective across. If you think any of my points are invalid, please enlighten me with some sort of source. I genuinely love being proven wrong because I’m on the DevForums both to learn and to help others learn.

  • :GetTouchingParts() must have a TouchInterest if the parts involved have collisions disabled, as written here which was already referenced by @SharpSerious.

  • Using the Touched event with an onTouched function is only necessary if the user wants immediate detection. There may be cases where waiting a few dozen steps is inefficient for their situation. Even so, they would need to be careful coding with this method to avoid accidentally using too many resources, which is why I proposed it as only viable if an immediate detection were required.

  • If immediate detection isn’t required, then using a loop to run a :GetTouchingParts() function every 0.5 seconds is perfectly fine. The function is not inefficient in detecting parts that are touching unless the collisions are off and there is no TouchInterest, which is why the first point was made.

  • Even if these methods were somehow incorrect, I wouldn’t be able give your method any more merit since it uses deprecated features. Even if they work, they are still deprecated for a reason.

I don’t mean to come off as disrespectful, but I would prefer you provide a source as to why any of these points are invalid.

1 Like

those Region3 functions were replaced by the new OverlapsParams API

1 Like

from what I know they like to reply to a lot of posts, some who already have solutions

they seem to think that they are always right as well

They deleted a message which was important to the context of why he said that. It was even worse than the viewpoint you’re seeing from.

1 Like

he is a troll, he took my working program and sent a screenshot of a false result in order to make my program seem as if it were not working.

1 Like