This checks the following things:
- Validity of UTF-8 encoding of title, author, and page content
- Maximum soft and hard lengths of title, author, and page content (soft
limits may be bypassed by uncancelling PlayerEditBookEvent; hard
limits may not be bypassed)
- Maximum number of pages. Books with more than 50 pages may still be
edited, but may not have new pages added.
I've stuck to only doing this in the places where I'm sure we should never get false back. Other places I'm less sure of (and I found more bugs along the way).
we don't usually add VanillaItems entries for blocks since they already exist in VanillaBlocks, but air has a special use case specifically as an itemstack, so we make an exception for this case.
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 9b52af62b6.
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.
