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

I was wondering whether teleporting a part that has entered the zone to a position outside the zone is supposed to break the behaviour of the partEntered functionality. Currently I’m facing this issue. It fixes itself when the same part enters the zone again and exits out of it.

Does the exit function need to fire for the enter function to work again?
If so is there a way I can manually do that to make the enter function work again?

1 Like

Assuming a part is already in a zone then yes, it would have to exit the zone before the entered event can be fired again. I can’t see how this would be a problem though?

If you are teleporting a part outside the zone and the exited event didn’t fire then that would be a bug. Could you explain what you’re trying to do in more detail?

Also note that part events only work for unanchored parts.


Thanks for the response. What I originally tried to do was to teleport the part that entered the zone to a specific position. So the code would’ve looked like this:

-- "Part" is a ball and un anchored when entering the zone

-- zone.partEntered() event fires
Part.Anchored = true
Part.Position =
Part.AssemblyLinearVelocity =
Part.Anchored = false

As you mentioned, the problem seems to be with the anchored part. I didn’t know about this before. I have now modified my script to work accordingly with this behaviour in mind and is working properly. Thanks


No problem, I don’t think I mentioned this in the docs so I’ll add a notice to make this clear

1 Like

You can set a name property to achieve this or user zone.groupParts, explained in more detail here:

In short, if your zone contains multiple parts and you want to retrieve an individual parts name from that zone when you enter it, you should instead split these parts up into their own zones each, then set a name or instance property for each and check for this.

There’s no change to performance when you split up zones so this is the best solution. For example, 1000 zones of total volume 500 studs squared is equivalent in performance to 1 zone of volume 500 studs squared (for the player events at least).

1 Like

Is it possible to do without using parts, maybe create a zone using positions?

Not for v2 since most of the Region3 checks are casted over characters which then check for zone parts - this requires these parts to remain in workspace. You can learn more about the methodology here:

1 Like

Hey, I’ve been having issues with your module, 10% of the time it would work and the rest of the time it wouldn’t, I don’t know if it’s a problem with my code but it seemed to work with the touched event prior, so perhaps we may talk somewhere to fix this? that’d be great.

Im pretty confused how to use this. What to do with the Zone module script? What do i need to do to make a Ambience Zone?

It’s recommended you place the Zone module in ReplicatedStorage. After that, create parts to engulf and represent your zone, group these together, then require this (a model, folder, or even a single basepart) within the constructor (as the zoneGroup):

-- Assuming we place ZonePlus in ReplicatedStorage
local Zone = require(game:GetService("ReplicatedStorage").Zone)
local zoneGroup = workspace.SafeZoneGroup
local zone =

You can then listen for events, such as a player entering or exiting that group of parts:

    print(("%s entered the zone!"):format(player.Name))

    print(("%s exited the zone!"):format(player.Name))

Or you can use methods to retrieve an array of everyone within:

local playersArray = zone:getPlayers()

You can find these details at the docs.

You can find an Ambience example (which checks for the local player instead of players) under StarterPlayerScripts at the ZonePlus playground:

1 Like

Thank you for the Information!

@Lobestone @R_alatch Detection support is finally here with the release of v2.1.0:

You can learn all about this under the new Optimisations section of the docs:

Feedback on anything you discover would be much appreciated! You should find ZonePlus scaling for hundreds to thousands of players when applying the new optimisations (such as setting Detection to Centre).

1 Like

Thanks, I’ll try it out for sure.

It seems to think I’m going in and out of the zone when I have one arm inside. Did I do something wrong?

local zoneService = require(game:GetService("ReplicatedStorage").Zone)
local safeZone =

safeZone.enterDetection = safeZone.enum.Detection.WholeBody
safeZone.exitDetection = safeZone.enum.Detection.Centre

	player.Safe.Value = true

	player.Safe.Value = false

What’s going on is this warning here:

This occurs because as soon as the player enterers the zone, its detection snaps to ‘Centre’, however since Centre only captures the very central position, the player has now exited the zone, and it repeats and repeats until the players centre is within the zone or the whole body is outside.

This isn’t a bug, it’s more of a design pattern you shouldn’t be implementing (hence the warning, I only realised this after making the feature).

You’re welcome to set enterDetection to Centre and exitDetection to WholeBody, however the other way around just won’t work. Your next best alternative is keeping both exit and enter detection the same.

Oh, okay. I guess I’ll just set both to center. How do I set both detection methods at the same time because I didn’t really understand the use [setDetection] part?

The introduction page explains it best:

Simply give the name of the enum item you wish to apply and it will set both the exitDetection and enterDetection properties:


Enum details found here:

1 Like

Is it possible to make it worked with lighting and atmosphere effect?

Depends what you want to do? If you want to change a Lighting property when a player enters of exits a zone then that will be easy enough.

1 Like

Do you have any examples of this?