to be consistent, these shouldn't be exposed in the API like this...
I'm not very happy with the whole 'type ID map' paradigm (particularly its lack of static analysis guarantees), but the most important thing right now is to get this stuff out of the API so that plugin devs don't try and abuse it. We're not going to change the whole system days before PM5 release.
while I could implement server-side ability to disable entity movement, I don't think that's particularly useful. However, the intended function of this (disabling client sided AI) is useful, so it makes more sense to rename it to match its functionality, rather than changing its functionality to match the name.
closes#3130
since most blocks have no state data, their lower 8 bits of state data were all zero.
This makes state IDs a bit more distributed for minimal cost.
I considered flipping these around and using type ID in the lower bits directly, but this worsened distribution for walls.
In the worst case, largest number of collisions drops from 11 to 5 with this change, and the number of states with unique hash keys increased from 3518 to 4461 (out of 7638). This is still a long way from perfect, but it's a decent improvement, improving the overall load factor from 1.6 to 1.3.
related to #5604
the only use for this class is to facilitate random runtime plugin loading, and it's not complete even for that purpose.
Since nothing but PM uses pocketmine/classloader anyway, it doesn't make sense to have it outside the core. As with LogPthreads, it's just adding more maintenance work.
this is now supported thanks to the object rescue feature implemented in pthreads 5.1, making returning of thread-safe values from async tasks possible.
This needs to be explicitly supported, since otherwise it will attempt to serialize them, which isn't supported anymore.
At the time when I wrote this code, I was still in the head space of the kind of ID hijacking that PM4 plugins do to override built-in blocks.
However, this kind of internal ID reuse makes no sense in PM5, since said IDs are only used in the core itself at runtime to identify types and states.
Even if we were to allow overriding block deserializers, overriding serializers makes no sense whatsoever, since the original block would continue to exist and be accessible.
There is a case to be made to allow overriding the deserializer, but not for the serializer.
this was previously part of the abandoned package pocketmine/spl. It had to be separated in the PM3 days, because RakLib depended on it.
Since RakLib 0.13, RakLib stopped being dependent on or aware of pthreads, so it no longer depends on any thread-related packages.
It's also possible to absorb pocketmine/snooze and pocketmine/classloader back into the core with this in mind.
Due to the high cost of Item::serializeCompoundTag(), it's very costly to rebuild this every time we need it. This is sent during the pre-spawn step, where we need to minimize costs as much as possible.
right now, I don't see an obvious reason to do this. If it turns out I was wrong later on, we can add functionality back, but we can't remove functionality after release.
