Zone+ v1 (deprecated) | Retrieving players within an area/zone

[BaggyChris (chris)]

Will this work for jumpscares?

[Devolas]

This helped a lot, thank you!
(30 chars)

[ShinsokuDev]

I really love Zone +, but for some reason it isn’t working for me:

local RP = game:GetService("ReplicatedStorage")
local ZP = require(4664437268)
local ZS = require(ZP.ZoneService)
local zonePart = game.Workspace.ZonePart
local zone = ZS:createZone("Zone", zonePart)

--------------------------------------------------------

local playersInZone = zone:getPlayers()

zone.playerAdded:Connect(function(plr)
	
	print(plr.Name.." Joined!")
	
end)

zone.playerRemoving:Connect(function(plr)
	
	print(plr.Name.." Left!")
	
end)

zone:initLoop()

Nothing will print, and I won’t get any errors (ZonePart is a Part with CanCollide off)

[7z99 (cody)]

I think the zonePart variable has to be a folder or model. Either one should work.

[ShinsokuDev]

Thank you so much!!! I spent hours trying to find my mistake and just couldn’t, you’re a life saver!

[megukoo]

Hi, what are the best practices for setting up a zone / the limitations of this?

Currently I had just set up multiple zones, building on from the first one I had implemented as a test.
Here’s what they look like in studio (color-coded)

Having all these zones enabled with a basic playerAdded and initLoop shoots my server Script Activity usage up to 25-30%. (I’m assuming this from the MicroProfiler as well as disabling/enabling)

The same amount of zones works fine on the client without any significant frame drops.

Is the problem the number of parts the zones are over? Should I create flat zones under the map and use the height parameter? I’m wondering if I can find a solution to this, for now I’ve temporarily disabled them on the server. Any help is appreciated

[ForeverHD (Ben)]

Good question, I’ve included a Best Practises section to cover all your points and some additional:

@ForeverHD

Best Practices

Zone+ provides an efficient way to determine players within an area, however is not always the best solution :

1. On the server, zones should be relatively small areas (ideally no more than 200x200x200), otherwise Region3 checks begin to become expensive. Minimise the volume of your zones where possible.
2. On the server, Zones should not be used extensively and should not cover a large proportion of a map. Zone+ is optimised for minimal, small zones. If you wish to cover a lot of your map, instead consider setting up zones on the client, or creating your own system which fires a ray from all players instead of performing additional unnecessary Region3 checks.
3. When using zone events (and calling :initLoop() ), or calling your own loop, keep the amount of calls per minute to a minimum. By default when :initLoop() is called (with a default delay of 0.1), 600 checks will be performed per minute . Instead, by specifying a delay of 3 seconds (i.e. :initLoop(3) ) only 20 checks will be performed per minute ). Obviously the greater the delay, the greater the potential period it takes for a zone to detect a player has entered or exited.
4. On the client, when using events call initClientLoop() instead for situations where you only intend to check for the local player (e.g. for a local ambient system).
5. On the client, a raycast is fired for every zone. (i.e. ray*zone*(1/delay) per second ) due to its object-like nature. While this has a negligible impact on performance, creating your own system which simply fires a ray every delay from the local player’s HRP is more efficient (i.e. ray*(1/delay) per second instead)

In short, for your situation, use Zone+ on the client, minimise the height (therefore volume) of your zones where possible, and specify a longer delay for the loop, such as :initClientLoop(3).

@megukoo

Should I create flat zones under the map and use the height parameter?

If a collection of zone parts have a height of 10, while another has a height of 9 and an additionalHeight of 1, then they both effectively have the same height (and volume). Reducing any zones total height though will improve its performance (this is negligible for small zones).

[Lord_BradyRocks]

Hello, Great Zone+
If you keep the zone area 200x200x200 or less, on average how many zones can you have and not see performance issues?

10, 20, 50 , 100?

Thanks!

[ForeverHD (Ben)]

This depends on a few factors you’ll need to determine yourself:

• Whether the zone is on the server or client (and calling initClientLoop)
  If the latter, a zones volume can be as large as you like with minimal-no impact on performance as it only performs raycast checks. Otherwise if server, then you will notice performance impacts the greater a zones volume due to additional Region3 checks.

• How often checks are performed
  You could construct 1000 zones of size 1000x1000x1000 and be perfectly fine. It’s when you begin to call :getPlayer() and :getPlayers() frequently (which initLoop() does 600 times per minute per zone unless you specify a greater delay such as initLoop(3)) for lots of zones where things become extremely intensive. For instance, if you have 100 zones of size 200x200x200 and call initLoop() on all of these without specifying a delay, you’ll be performing 60,000 Region3 and Raycast checks over a volume of 800,000,000 studs cubed per minute. That’s going to hurt.

On the server, If you intend to setup lots of zones on the server with large volumes, or if your zones cover your entire map, you’ll honestly be better off setting up your own detection system which fires a raycast from every players HRP every interval.

Zone+ events on the server are primarily optimised and intended for servers with lots of players with zones that do not cover a large proportion of the map.

[Maxx_J]

Just wanted to point out that the current code doesn’t seem to support wedges or parts at odd angles. Only partial workaround this is by unioning said parts.

[R_alatch]

I’m having an issue where it only makes a zone for one part in the model I am making a zone out of. This is my code:

local serverStorage = game:GetService("ServerStorage")

local zonePlus = require(4664437268)
local zoneService = require(zonePlus.ZoneService)

local zoneParts = workspace:WaitForChild("ZoneParts")
local zone = zoneService:createZone("ArenaZone", zoneParts)

local items = serverStorage:WaitForChild("Items")

zone.playerAdded:Connect(function(player)
	if player.Character then
		items:FindFirstChild(serverStorage.PlayerData[player.Name].EquippedItem.Value):Clone().Parent = player.Backpack
	end
end)

zone.playerRemoving:Connect(function(player)
	if player.Character then
		player.Character:FindFirstChildOfClass("Humanoid"):UnequipTools()
		
		local item = player.Backpack:FindFirstChild(serverStorage.PlayerData[player.Name].EquippedItem.Value)

		if item then
			item:Destroy()
		end
	end
end)

zone:initLoop()

[ForeverHD (Ben)]

Your code appears to be fine at a glance. Can you send a picture of zoneParts and their descendants in workspace? Have you made sure the parent is a model or folder?

[R_alatch]

Sure.

[Greeny_Alien (Greeny)]

I’m making a room detection system for my game and it’s worked great so far to detect which room each player is in.
I know this isn’t a feature of the module, and neither is it intended, but what do you suggest for detecting non-player objects such as a thermometer detecting which room it is currently in.

[ForeverHD (Ben)]

There’s a few methods you could use in your scenario and it ultimately depends on how your tools/objects behave (i.e. can they move at all, can they be picked up by players, etc).

First idea which springs to mind: group invisible parts together to represent a room and place them slightly below the room itself, then whenever you need to know which room the thermometer is in, fire a raycast downwards and if it hits one of these parts you can deduce which room its in.

[Planet_Dad]

Has anyone used this for hitboxes? All the existing solutions I have looked at aren’t good for my use case so far. using just regular .Touched doesnt reliably fire if the hitbox isnt moving.

[isaiahbur]

I was wondering this aswell while looking at this topic.

[ForeverHD (Ben)]

Zone+ can be used to generate hitboxes. Keep in mind it’s primarily intended to work with static areas as apposed to dynamically changing areas. For this reason I’d explore other resources such as swordphin’s Raycast Hitbox module:

Raycast Hitbox 4.01: For all your melee needs!

Current Version: V.4.01 Stable (09/21/2021) Upgrading from 3.xx to 4.0 Please note that V4 is not backwards compatible with V3. There are a few API changes that were introduced in V4 to better suit modern code etiquette. Here are the changes you need to know if you want to make your code compliant with V4: Raycast Hitbox 4.01: For all your melee needs! - #597 by TeamSwordphin Notable Features Accurate, performant, and easy to use! Use attachments or vectors to make your hitboxes in secon…

[sas_rbx (sas)]

Hey I’ve been using Zone+ recently (it’s an amazing module). However, I’ve been running into some problems recently.

I’ve been making two zones for a music changer and an environment name popup thingy. There has been this bug and it’s IS SO FRUSTRATING. This is happening on the client (I use it correctly):

This is a class that is integrated with Quenty’s Binder class

function EnvironmentRegion:_connectModel(model)
	local zone = Zone.new(model)
	
	zone.playerAdded:Connect(function(player)
		print(player.Name, "has entered", self:GetEnvironmentName())
		EnvironmentName:Set("DisplayedText", self:GetEnvironmentName())
	end)
	
	zone.playerRemoving:Connect(function(player)
		print(player.Name, "has left", self:GetEnvironmentName())
	end)
	
	self._maid:GiveTask(zone)
	zone:initClientLoop(0.01)

	print("Created EnvironmentRegion Zone For Model:", model:GetFullName())
end

-- I know this says MusicChangePart but it is actually a model (i'm looking to
-- change the name later)
function MusicChangePart:_connectModel(model)
	local zone = Zone.new(model)

	zone.playerAdded:Connect(function(player)
		print("Switch background music")
		SwitchBackgroundMusic({
			SoundId = self:GetAudioAssetId(),
		})
	end)
	
	zone.playerRemoving:Connect(function(player)
		print("Left background")
		SwitchBackgroundMusic({
			SoundId = SwitchBackgroundMusic.DefaultBackgroundMusic,
		})
	end)
	
	self._maid:GiveTask(zone)
	print("Created MusicChangePart Zone For Model:", model:GetFullName())
	zone:initClientLoop(0.01)
end

The major problem is that the behavior is extremely inconsistent. Sometimes, one zone works. Sometimes the other. Sometimes both zones work, and sometimes none work. It is really frustrating.

Also, It prints that the zones are created (both zones). I think it’s something to do with playerAdded and playerRemoving.

No errors at all.

Thanks.

[DeathLilian (Alyssa)]

Will this worked with lightings and atmospheres on only player client that won’t affect other players client?