if the NBT is bogus for some reason
in PM3, these kinds of bugs wouldn't show up until/unless the item NBT was actually used, but on PM4, we decode it ahead of time, so the errors always show up immediately.
this makes just about everything easily accessible via commands.
There are some stuff that shouldn't be here due to not being actual items (e.g. door blocks, bed blocks, wall coral fans) but since there were legacy aliases for all those things already, I figured what the heck - it's more effort to exclude them, so whatever.
this isn't specced up with some of the finer features of LegacyStringToItemParser such as metadata parsing, but those are still a work in progress (and probably limited to specific items like durable stuff).
The goal is to unbind these aliases from legacy internal IDs, while also providing a nice flexible way for plugins to add their own items and aliases to the existing system.
This system allows mapping a string to any item at all, irrespective of state, internal IDs, or any of that nonsense. This means it's finally possible to have stuff like lapis_lazuli and bone_meal aliases in commands.
this doesn't implement the server-side logic for the "stickiness" (slowdown) because we don't have the system needed for it yet.
It also doesn't have parity with vanilla on the damage.
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.
this implementation is very rough due to having to hack around lots more MCPE bullshit, and currently doesn't allow dynamic coral types; but it's there. We'll clean this up after 1.13 migration is done.
Player->useHeldItem() assumes that if the old item == the new item, we want to set the item back into the inventory if it's modified in-place. Therefore, we don't modify the item in-place to bypass the problem.
closes#4022
originally I introduced this to make it easier to implement the various APIs addPattern removePattern etc, but those were later removed in favour of simple getPatterns() and setPatterns(), allowing plugin developers to use ext-ds APIs to manipulate patterns.
However, ds poses a number of headaches because of mutability combined with by-ref semantics, which make it a pain to use these on the APIs because we can't guarantee that they won't be modified.
As much as arrays suck, they have two significant advantages over ext-ds: 1) they have copy-on-write semantics, and 2) they support PHP 8.0 without any extra work from me.
