Development/Border Events
=== DEVELOPMENT ===\--[ border events ]--/

In case 1 (observing the situation of the guy marked with the 1 number) he is not in any zones (only in the world global). Based on that, it seems logic, that all zone should be checked if whichever he may stepped inside. The case is much more well written in this plugin than in other ones, because performance is needed, a zone handler plugin must be fast as possible, because it works with lots of resources. So I used the logic of minecraft chunking, and chunked all the zones. There you can have your question: "But one block goes into one chunk. Zones on the other side can be large and be in many chunks!" Yeah, you're right. The chunking is not for saving however, it is dinamically generated runtime and freed if not needed. It is like you get ball with colors meanwhile there are people, who are asking to give them balls with specific colors. You will separate the balls with different color as soon as you get it, and for example if a guy asks for a blue ball, you will give them from the box which contains the blue ones... it is much faster, than searching for a blue one between all of the balls. Yeah, it's not that hard to find a blue ball, is it? But if the difference is less visible or takes time to observe, or the colors are many in number... it sure will fasten up the work, if you group them by their properties. In Zure however, the "boxes" are not based on the zones themselves, because not the zones are changing under its hand, but the players and the locations. As a location is reached, Zure creates a zonechunk for it and buffers the data into the chunk about the environment. Based on this system written asynchorous, chunk initialization won't slow the server causing lower TPS, and much like you can have any amount of zones in your worlds, it won't cause more calculation per player, because players will still check only the zones close to them (in the chunk they are inside). So this is the base of the fast zone handling, the chunking mechanism. But that's not all, if I would have only this thing... this is pretty good already. But I wanted more performance. As much as possible. Many players walking around, and calculations run in every tick for every one of them. If I can boost up only a little bit more, the time advantage will be multiplied up 20 times in a sec by the tps, as well as slow code runs 20 times a sec too, so the time of the calculation is very important here.

On the picture, you an see, that [A] and [c] do collide and have a shared region together. Sure, the one with the more priority dominates, but it's not that, what is insteresting here. Please take a look at the guy signed as the second. He is inside [A], and his thought bubble show, what calculations are needed for him. He is wondered, if he leaves [A], enters [b] or enters [c]. That's all, what is important for him. He is not needed to take care about other zones, far away, or [b], which is also farther a bit. But knows about [b], a subzone of [A], subzones are always must be checked of the zone you are inside. That's clear thing, I think. And then [c], because it have shared region with [A]. If I checked these three regions, I'm fine to say, I know all things about the player if he entered into of left a zone. Sure, things become more interesting, when we get to observ specific cases, so let's see the first:
[under writing]
Comments