it's now the World's responsibility to manage adding/removing entities from appropriate chunks. Entities no longer know or care that chunks exist.
Entity->checkChunks() remains as-is for backwards compatibility - now it just calls the world to sync its position.
if a PopulationTask took place after the target worker was garbage collected, the population would fail and the chunks it used would be copied for nothing.
This change marks workers as having unregistered generators when detecting that a worker that previously had a generator registered is restarted.
a non-generated chunk is now always represented by NULL. This forces the case of ungenerated chunks to be handled by all code, which is necessary because ungenerated chunks cannot be interacted with or modified in any meaningful way.
in cases like PopulationTask it makes more sense to store the coordinates separately where they can be stored more efficiently (once instead of 9 times)
In addition, PopulationTask shouldn't need to serialize an empty chunk just to copy coordinates.
I've made changes like this in other areas already in preparation for the day when chunks no longer contain their coordinates, so this brings us one step closer to that goal.
this only made sense to work around the server crashing when creating a player in ungenerated terrain, but spawning at y=256 is hardly preferable, and it'll crash since fd99445c5bbd2a5a6fdd0109d8a196ea6160e0a3 anyway ...
previously this created an empty chunk for the entity to hang around in until the terrain was generated, but that's problematic for several reasons, most importantly the fact that non-generated chunks are not saved.
instead, it will fire when the chunk comes out of PopulationTask and is set into the world using setChunk().
There is still one place left where auto-creation of empty chunks is used by the core, and that's an issue i'm still deciding how to deal with.
I'm of two minds whether this should continue to fire onChunkChanged() on chunk loaders or not, since the chunks won't be referenced by any chunk loader anyway by virtue of not existing ...
this fixes#3906.
TimingsHandler will now be automatically destroyed when there are no TimingsRecord referencing it and its owner has no references left to it.
TimingsRecord will be automatically destroyed at the end of the timings session (if active).
This fixes records from temporary timers being lost after the timings handlers are removed, while also fixing TimingsHandlers piling up regardless of whether timings are running or not.
This opens the doors to have more volatile timers, such as per-player/per-session timers, which are destroyed on player quit, but which won't result in the timings disappearing from the final timings result.
regardless of how long an async task takes to run, it will take a multiple of 50ms to get the result processed. This delay causes issues in some cases for stuff like generation, which causes locking of adjacent chunks, and async packet compression, which experiences elevated latency because of this problem.
This is not an ideal solution for packet compression since it will cause the sleeper handler to get hammered, but since it's already getting hammered by every packet from RakLib, I don't think that's a big problem.
this gives a bit more control over how packets are broadcasted, which might be useful if the batch format changes (e.g. adding a length prefix) for multi version.
This really ought to be unique to a protocol context instead of a network interface, but for now this is the best we can do.
there is no longer such a thing as a permission granted to 'everyone', since we're no longer limited to true/false/op/notop, and regular players are now assigned the pocketmine.group.user permission.
It's possible we might want to add more restricted groups than 'user' in the future, in which case it would be behaviour-BC-breaking to change the default assigned permissions when creating a new PermissibleBase. Therefore, it's better to not assign any permissions at all and let the caller decide.
In addition, this solves the problem of implied permission subscriptions and leak on PermissibleBase construction - if base permissions are provided, it should be expected that the permissible will subscribe to those permissions.
