The previous layout and class hierarchy of the skeleton API defined
variances of the skeleton, such as the wither skeleton or the stray, as
child types of the normal skeleton variance, which is technically
incorrect, yet did not produce any specific issue as the normal skeleton
variance did not have any unique logic.
With the introduction of powdered snow in the 1.17 update, the normal
skeleton variance now has unique logic, specifically the conversion to
a stay when stuck inside powdered snow, which cannot be represented in
the current API layout due to the prior mentioned hierarchy.
This commit implements the hierarchy changes made in the bukkit
repository by representing the new hierarchy on the craftbukkit side
through the CraftAbstractSkeleton and the respective additions to the
skeleton implementation in regards to the stray conversion.
This commit does not break ABI yet breaks backwards compatibility due to
the mentioned hierarchy changes. Plugins that previously used the
Skelton interface to compute whether or not an entity is skeleton-like
through instanceOf checks will now only match the normal skeleton variance
instead of any skeleton-like entity.
Previously spigots chunk pdc loading logic would read the entire chunk
nbt compound into the persistent data container of the chunk instead of
just reading the "BukkitValues".
Furthermore this commit also now correctly checks if the nbt compounds
of entities, tile entities and chunks actually have a value for the
"BukkitValues" key, as the previous 'getCompound' call would always
return an instance, the null check was useless. This commit now uses
'get', which returns null if no key exists and then runs an instanceof
check to both validate a non-null instance and an NBTTagCompound
instance.
While cfeef75cd97 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 cfeef75cd97 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.
Non-persistent entities won't get saved when the chunk saves the entities.
Entities that are passengers of a non-persistent entity won't get saved.
Players won't save their vehicle, if the player is directly or
indirectly riding a non-persistent entity.
