While 9862a0135d might of semi helped being able to save black text
lore, it actually took a fundamental problem with the legacy serialization
code and expanded it to break even more aspects of the server when dealing
with Component to Legacy conversion.
This is causing data loss in Spigot with cases such as setting an item name
to white gets stripped resulting in it being italic.
Additionally, things such as book pages have been returning black formatting
codes for the end of the line even when the user doesn't have colors in the book.
The root issue is that the "Default Color" system is fundamentally wrong.
Components do not and should not care about what element of the game they
are being used by, and that's what the default color system did.
It results in components that if obtained from 1 source such as a Book
where the default / rendered color is black, is then copied to another
source such as an Entity name, the black is carried forward and shown
in the Entity name, when in reality it should have been white.
This commit reverts 9862a0135d and fixes the underlying serialization
issues when it comes to Legacy to and From conversions.
There was quite a number of issues with this code overall, in how
it handles inserting color codes, new line parsing and such.
Books was using mojangs own "getLegacyString" which doesn't match behavior.
We also do not want to use Mojangs method as there is no guarantee they don't
remove that in future.
Plus, everything about books uses the CB implementation anyways, and it should
be consistent (this was mandatory to avoid serialization format changes on old vs new)
These changes as is results in Item Stacks already serialized will not
change contents when they go to component and back, so this won't impact
any existing data.
Newly created books though for example will change behavior in that they
will no longer insert black color codes in the serialized data and will
only represent intentional color changes by the creator of the book.
This will result in cleaner data on them, and books are the only thing
I'm aware of that has a behavioral shift due to the likelyhood of the
default color system kicking in on other parts of the string.
A unit test has been added to verify integrity of serialization to
ensure that any legacy string that is converted into Components will
always re-encode back in the same way when going back to Legacy.
By: Aikar <aikar@aikar.co>
After this commit, spigot now creates a deep copy of the
itemmeta's persistent data container when the itemmeta
instance is cloned.
This change fixes the bug that, after cloning itemmeta, the container
instance the cloned meta would point to was equal to the original one.
This resulted in two itemmeta instances sharing a single persistent
container.
By: Bjarne Koll <LynxPlay101@gmail.com>
CraftBukkit (and Minecraft as well in some cases, such as when getting
an item from the creative inventory menu) will omit the Damage tag when
it is zero. However, minecraft will add the tag in some situations
nevertheless, such as when loading the ItemStack, or when explictly
setting the item undamaged.
These items (with and without the Damage tag for undamaged items) will
be considered as different by minecraft and CraftBukkit in various
situations, even though they should not. In CraftBukkit these items will
actually only be considered unsimilar if the items' metadata is not
'empty' (if it contains other additional metadata, such as enchantments,
etc.).
If the item's tag is empty after removing the Damage tag, it gets
completely removed. The setRepairCost function was adapted to behave in
the same way (removal of the tag if it becomes empty).
By: blablubbabc <lukas@wirsindwir.de>
Without this change the calculation of fitting items was incorrect, so event.getRemaining() did return 0 when it should not be 0.
By: Brokkonaut <hannos17@gmx.de>
