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?
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 = Vector3.new()
Part.AssemblyLinearVelocity = Vector3.new()
wait(1)
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
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).
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:
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.
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 = Zone.new(zoneGroup)
You can then listen for events, such as a player entering or exiting that group of parts:
zone.playerEntered:Connect(function(player)
print(("%s entered the zone!"):format(player.Name))
end)
zone.playerExited:Connect(function(player)
print(("%s exited the zone!"):format(player.Name))
end)
Or you can use methods to retrieve an array of everyone within:
@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).
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?