An improvement either way, wouldn’t you agree?
Sure but if its using already made systems that require not much work to include is it really that much of an improvement at all?
Im going to go shower.
I’m a bit confused here, the point of this discussion was around the performance of SimpleZone vs ZonePlus, I have demonstrated SimpleZone can run 313 zones without crashing, and 313 zones with minimum lag (with .fromPartParallel), whereas with ZonePlus, 313 zones straight up crashes my game (in Studio and on PS4). Both use Roblox’s Spatial Query API. The point of using 313 zones was as a point to say that if it can run this many zones without much lag, you can bet that it’ll run even better with less. Heck, if you still don’t like the performance, you can still use your own query function using SimpleZone.fromCustom()!, whereas with ZonePlus it is extremely hard to customize anything because the code is messy.
Honestly I don’t really feel like pushing this point any further, I’ll just let the performance speak for itself.
1 Like
Unfortunately I don’t think I can add the random point feature, as all of the information of a Zone actually is inside the .Query function, meaning I can’t really get a random point inside it unless I seperately store them in the Zone.
Just had a read of everything, seems to be good enough to make the switch over worth it. Do you plan on expanding the functionality to be similar to ZonePlus? also, are additional performance improvements planned and will we ever get to control the rate at which zones are checked?
1 Like
You can make your own rate of checking by manually calling Zone:Update() 
Also, yes, I will probably be adding more of the functionality that ZonePlus has like tracking items, or Zone groups.
In terms of more performance improvements, I honestly don’t really know because in my opinion everything is already pretty optimized, but if you have any ideas feel free to let me know!
I was trying to get a .fromBoxArrayParallel() to work, unfortunately with the current system of 1 Actor per zone it doesn’t really work great 
Currently working on an ActorGroup utility module to get around this
Yeah I don’t think I’m gonna make a .fromBoxArrayParallel(), .fromBoxArray() is plenty fast enough 
Update: Added the Zone:TrackItem(...) method! Documentation has been updated to reflect recent updates
Honestly I’m contemplating if I should just get rid of the other constructors, .fromBoxArray is really really smooth 
Let me know what you guys think
Update:
Renamed .fromBoxArray() into .fromBoxes()
Removed the .fromBoxParallel() constructor in favor of .fromBoxes()
If you are aiming for fastest performance then id recomend to reduce the indexxing
What im saying is you can turn “table.freeze()”
into a global variable
“local tablefreeze = table.freeze”
For example
when you call table.freeze the script looks for all the functions in table until it finds table.freeze
you should reduce many checks to one check
Even if this is super optimised you should find the best workaround
Also one more thing. In luau you dont need pairs() in most uses so you can reduce it alot
But when your reducing the indexxing you should take this thing in account
Lets say you need to change the name of someting rapidly. So you change
“part.name” to “local partname”
but when you change “local partname” to a different name then it wont change “part.name”
local taskwait=task.wait
local instancenew=Instance.new
local Part=instancenew("Part")
Part.Name="0"
local partname=Part.Name --name is "0"
local number=0
while true do
taskwait(1)
partname=tostring(number)
number+=1
if number==50 then
break
end
end
--prints "0"
I have seen a noticable change in preformance before
If you are failing to understand what im tring to say then feel free to reply to me (i dont check devform much)
Wait, I was looking back at older posts and this module is only used to detect a player in a bigger part?
No, using the .fromBoxes() constructor I recently added you can add multiple bounding box detection areas to 1 Zone.
Actually, it’s quite the opposite!
Directly indexing library/builtin functions are faster than redefining them as other variables because of FastCall.
For example,
local readu8 = buffer.readu8
local result = readu8(somebuffer, 0)
is slower than doing
local result = buffer.readu8(somebuffer, 0)
This is also the reason why people do task.wait() instead of local taskwait = task.wait
1 Like
Wow I am just flabberghasted and bamboozeled
I have never let go of that method of trying to optimise
I didnt really know that
Thank you for that crucial information👍
But what about calling task.wait() multiple times
Yes, itd still be as fast or maybe faster.
1 Like