'enchant' just didn't feel right, being a verb.
All these things pertain to the act of enchanting.
This is now also consistent with CraftingTransaction etc. The ship already sailed on EnchantInventory, which will have to be renamed at a later datte. However, that was already inconsistent with 'enchanting table', so that's the odd one out here.
this is a really dumb bug and seems similar to the armor bug I fixed a while ago.
fixes#5987
it's unlikely that #5727 will be solved by this, but one can hope...
until now, any thread crash would show as a generic crash since we aren't able to get the trace from the crashed thread directly. This uses some dirty tricks to export a partially serialized stack trace to the main thread, where it can be written into a crashdump.
This enables us to see proper crash information for async tasks in the crash archive (finally!!!) as well as being able to capture RakLib errors properly.
normally I would hesitate to reinvent the wheel, but we only need a tiny subset of the ASN.1 spec which is trivial to implement by itself.
I'd rather this than depend on another library that could introduce security vulnerabilities (I'm looking at you, jsonmapper).
closes#5935
if users want these, they can broadcast them themselves using Server::broadcastMessage(), which will also record the message in the server log like chat
closes#5669
since we don't have a hard date for this, and I've already made one wrong educated guess, I'd rather not have another massive outage.
A security update will have to be made to remove the old key as soon as the new one is rolled. This is not ideal, but it's the least disruptive option.
Since task execution depends on tasks executing sequentially on a particular worker in some cases (e.g. PopulationTask must be preceded by GeneratorRegisterTask), it doesn't make sense to continue task execution if an error occurs.
Moreover, a task crashing may render the whole server unstable, as it leaves the server in an undefined state. This is the same kind of problem we fixed with scheduled tasks in PM3.
In versions past, pthreads was unreliable enough that random tasks would crash without an obvious reason, forcing us to accommodate this. I still don't know the origin or frequency of said issues, but I think it's time to rip the band-aid off and solve these problems for real.
this coincidentally fixes mangrove doors being tagged with unwanted blockstate runtime IDs. Their items client-side are not actually blockitems, so the client doesn't expect them to have blockstate IDs attached.
This reduces the chaos in the creative inventory slightly (for some reason the client responds to this stuff by putting random creative items in the wrong places), but the mess is still substantial and I don't know what caused the rest of it.
closes#5818
technically we shouldn't be breaking BC of internals signatures in a patch release, but it's internals, and that's an unwritten rule anyway. In any case, no one is likely to be affected.
This reverts commit 9baf59702bf63453d071c92150823e1a0683d025.
I forgot this is also needed for the player list, and for skin updates
to work ... this will need to be revisited
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
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.
