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

I’m having some trouble here. Not sure if I’m doing this incorrectly but the player exit zone signal will fire even if I’m inside the zone. Maybe I’m misinterpreting the function of this resource. Not sure but, any help would be greatly appreciated.

Screenshots and a Video

This whole model is what I’m using for the zone.

“In” - Outputs whenever a player enters the zone, which would be whenever a player enters a facility.
“Out” - Outputers whenever a player exits the zone, which would be whenever a player leaves the facility.

However, the exit signal fires EVEN if the player is in the zone. Help would be greatly appreciated.

Oh and a screenshot of the code if you need it. Cause you know, I could be typing all of this for one dumb small mistake lol.

2 Likes

Would this be the entire HRP or just its central position, and what benefits would this provide to you?

2 Likes

Zone parts have to encapsulate the entire area of where you want players to be detected. I’d recommend using 2 rectangular parts to cover your whole building, making these parts invisible, anchored and uncancolidable, then only using these parts as the Zone group parts.

4 Likes

Central position, and to fix the player being able to stand outside the zone with just a fraction of their arm in the zone and still be considered inside the zone.

1 Like

This is something we’ve been considering, likely by introducing a bool or enum property to chose between whole body and just the HRPs centre.

If set to ‘centre pos’, this likely would have to be for both playerEntered and playerExited (instead of just playerExited). Would this be fine?

2 Likes

To be entirely specific, I would like playerExited be center position and playerEntered be the whole body, but center position for both would be fine as a toggle.

1 Like

Sure thing, we’ve opened up a ticket and I’ll aim to complete this during some spare time over the next week:

3 Likes

Looks great, I will be excited for this update!

Just came back to delete my post cause I just had that fix/idea. I feel very stupid lol. This might be the best resource to ever cross me on the forums. Wow you sir, are a legend.

2 Likes

How would you go about spawning a NPC with the custom scaling (BodyHeightScale, BodyWidthScale, etc) in a zone using the coin spawner example as a basis? I got the spawning of an NPC to work at a normal height (using R15) where using local distance = 3 would have feet flat on the floor.
Whenever changing the scale of the bases, to a random number between 0.65 and 0.9, the NPC would float. I’ve tried multiplying the distance = 3 by the scale as well as multiplying the CFrame from intersectionvalue by a CFrame with the scale and it still floats.
I’m aware this is more of a question for the code help category, but considering it’s a ZonePlus related thing figured I’d try here. If I need to move it let me know.

1 Like

Hello! Just stumbled upon this system and was wondering, how efficient is this system? Currently for my game what I do is (and this may be a little weird at first) is I create a region 3 around the player, a box of some sort, and have invisible parts (usually 1x1x1 and transparent/anchored/non-can collide) placed within a folder that I whitelist for the region 3 checks.

Additionally, I can create separate folder parents for organization or place an ObjectValue for further classification of what kind of region I am in. This generally results in O(1) in terms Big O algorithm complexity since I am having the do the same region3 checks no matter how many regions I decide to add into my game.

I am wondering if this system is any more efficient than my own and whether I should switch to it or not. Thanks again for this amazing opens source stuff @ForeverHD , always loved your work!

1 Like

A neat trick for calculating the height of a default character is by multiplying it’s HumanoidRootPart Y size by 2 then adding on the head Y size (since the legs are always the same size of the HRP). You can then extend this method to obtain the entire square volume of a character (the arms are always HRP X size divided by 2) and best of all it works with both R6 and R15.

2 Likes

WOW this pack looks great :star_struck:!
try adding a low gravity zone in the next update!

1 Like

Hi there, I’d highly recommend checking out the methodology page which explains all of this in detail:

In short, ZonePlus is dynamic therefore the methods vary depending upon the events you use and other factors such as the total volume of characters, parts and zones.

In short, the player-detection method (when the total volume of zones exceeds the total volume of characters) sounds similar-ish to yours, except it utilises EgoMoose’s RotatedRegion3 module with whitelists.

Zones are also abstracted to appear as singular entities (for ease of use) however behind the scenes act as a collective for optimisation reasons (i.e. they share data instead of generating it individually).

We’re also exploring new optimisations mentioned here - when ‘Detection’ is set to ‘Automatic’ ZonePlus will dynamically adapt the size of these region checks (i.e. striking a balance between accuracy and performance) to allow for hundreds of players in a server with negligible effect on performance.

1 Like

Amazing! Keep on doing the amazing work you are doing!

Ah, alright! So it seems like you have a Rotated Region3 the size of the player’s character on the LocalPlayer implementation and use the zones as whitelists to check if the player is within them? Sounds neat! Is the Rotated Region3 module by EgoMoose any more efficient than the Roblox implementation of Region3’s or is the reasoning behind your usecase due to it supporting rotated Regions?

And looking at the documentation, if I disconnect the events, the checks no longer work correct? That’s much neater than what I had implemented considering the checks don’t do any extraneous work other than checking the players region.

Again, thank you!

Roblox regions don’t account for rotation or special shapes like wedges. EgoMoose’s RotatedRegion3 uses clever math and is built ontop of roblox’s Region3 methods to account for rotated parts and different part types.

Correct yep, when all zone connections (like that returned from .playerEntered) are disconnected, or if the zones are destroyed (zone:destroy()) then checks will cease.

Really nice module, worked perfectly to create a system to generate parts over a dynamic terrain. Good job! :grinning_face_with_smiling_eyes:

We’ve been using this for a server with up to 80-100 players
with a total of 34 zones.

Only downsides I’ve been seeing is that we have one tool relying on mouse.Target which keeps picking up the ZonePart because I thought I could just keep ZoneParts inside ServerStorage, but they actually need to be in Workspace. We simply just made the ZoneParts nearly the exact size as the roof all the way around so the player’s camera is always in the Zone.

I’ll be looking into this once you release Detection options! I just need to know if a player is in or not, not limbs etc.

I’ll be up for testing any performance gains!

1 Like

Thanks, it took a few days but I eventually got it. That led me in the right direction.

1 Like