This reverts commit 9b52af62b6f469771f2355a964b35ecffa5117d9.
We shouldn't assume that a string maps directly to a legacy ID,
because we might want string aliases (e.g. dark_oak_boat) which refer to
items that have a specific meta value in the MCPE system.
Overall, I want to get rid of the reliance on IDs here and register all
this stuff using closure callbacks on VanillaItems, so getting rid of
this assumption also serves that goal.
it's better to just implement this for stuff where there's explicitly designated aliases, otherwise we could end up with unexpected BC breaks (e.g. hardcoding POSTWORLD in plugin.yml would suddenly break if the core enum was changed, even though it remained valid).
this makes more sense overall from a reader's perspective.
and also provide a rug-jerk for any idiots using World->close() when they aren't supposed to? ....
this stuff has different functionality than everything else in the
command namespace (specifically console handling), so it doesn't belong
in here.
I know that this will probably break some plugins, but I don't care,
because plugins shouldn't have been abusing ConsoleCommandSender in the
first place.
this occurred because of transactions arriving before MobEquipmentPacket updating the player's own held item slot. This was only a problem while rapidly changing hotbar slots and simultaneously using items, like projectiles.
closes#4168
this is necessary to get rid of the broadcast permission callbacks, which retain references to the Player itself, forming a cycle which would prevent PermissibleBase->__destruct() from cleaning up.
since MCPE-19214 still hasn't been fixed after all these years, it's safe to say they won't fix it in the near future, and this causes placement glitches in PM.
since we write these into a transaction instead of actually modifying the world directly, we can use the transaction to verify that the placement location is OK before setting the blocks.
closes#4248
instead, use a const array of the offsets and add them to the coordinates, which avoids the allocations.
In synthetic benchmarks, this method takes 40-50% less CPU time by eliding ZEND_INIT_ARRAY and ZEND_ADD_ARRAY opcodes. In practice, the benefit will likely be much smaller (perhaps even irrelevant).
this can fail if the backups directory points to a different drive than the original worlds location. In this case, we have to copy and delete the files instead, which is much slower, but works.
I REALLY advise against putting backups on a different mount point than worlds if you plan to convert large worlds.
