SimpleZone | A simple, fast and new Zone module!

Resources Community Resources
, ,
#41

I honestly don’t think I will be opening a GitHub repository (I am EXTREMELY unfamiliar with it xd), but I might in the future!
In the meantime, if you have any ideas to add just say them here in the replies :slightly_smiling_face:

#42

Alright guys, I’ve decided to change :GetItemSignal() to :ListenTo(), as it was creating unecessary RBXScriptSignal objects.

#43

For anyone who has code using :GetItemSignal(), I would replace them with this :sweat_smile: sorry

#44

Personally I don’t care how the code base looks for a resource as long as it works well and doesn’t mess with performance that much in a bad way.

If you could provide some evidence and reasons why this would be a lot faster then I might consider swapping over.

1 Like
#45

Yes, I am currently comparing the performance of ZonePlus vs SimpleZone, please wait until I can finish the tests :slightly_smiling_face:

Although, I do have some reasons why this would be alot faster:

  1. SimpleZone uses SimpleSignal for events, which is faster than GoodSignal because it uses lookup tables to store connections instead of linked lists.
  2. SimpleZone uses lookup tables to get a player from a body part instead of using Players:GetPlayerFromCharacter() (as of the latest version), as the index operator is faster than any method call, this also makes SimpleZone faster in this aspect
  3. I recently added a .fromPartParallel() constructor to SimpleZone which uses actors for the spatial queries, making it significantly faster than doing spatial queries in serial.

These are really the only ups of SimpleZone I know to be true right now, just wait until I finish the tests and maybe there’ll be some more :slightly_smiling_face:

#46

But for now I wouldn’t really design any major scripting stuff with SimpleZone, as it is still growing and being developed :slightly_smiling_face:

#47

This is the only thing out of the 3 I really only care much about to be fair. The other replacements don’t really make much difference performance wise imo.

1 Like
#48

Well, if you’d like me to implement some specific optimizations/speedups you have in mind I’d love to :slightly_smiling_face:

#49

does it use native code generation

#50

Unfortunately native code generation wouldn’t help much here as SimpleZone interacts heavily with the game, ncg should really be used for math-specific operations in my opinion. Feel free to change my mind though :slightly_smiling_face:

#51

ok so uh bad news, creating 313 ZonePlus zones just crahed my Studio :frowning:

Benchmarks are coming soon guys, just let me restart it :slight_smile:

#52

i agree with that

btw i think you can use ncg here

image
image1124×778 91.7 KB

they’re recursive function and looping but it not that necessary

you can correct me if I’m wrong :pray:

#53

that’s an unrealistic number of zones to be honest. I don’t think anyone needs more than max 20 zones maybe 50 but even then you can unload and reload them either way.

#54

I am creating 313 zones for the purpose of testing, because if it runs 313 zones well it probably runs even better with less, I agree though

#55

I’ll try adding it and see if it makes it any faster

#56

It can’t run 313 zones well if it wasn’t designed for such a load. Good you agree though.

#57

Well yeah, but in my previous post I compared 313 individual zones using SimpleZone with and without actors, if SimpleZone can handle more zones than ZonePlus why not make the switch? :slightly_smiling_face:

#58

Because I don’t need 313 zones to be ran at one especially when you can mini manage it all on the client and validate with the server including other methods like unloading and reloading those zones when not needed.

#59

My point is, if it can run 313 individual zones with minimum lag, surely it can run even better with less?

#60

Right but it seems like a slight improvement just because its running in parallel not base. Its a near guaranteed improvement.