This patch prevents entities from riding a vehicle they're already riding on.
When trying to enter a boat the client will send up to two packets for each hand
causing the server to think they should enter the boat twice, despite the first
interaction being sufficient.
The flag for getChunkAt(int, int, ChunkStatus, boolean)
is actually a flag for whether to bring the underlying
PlayerChunk up to the required ticket level to load the
chunk. So, if the chunk is already at the required level,
but has not yet loaded, the call will actually either
start the load if it has not already been started and
block until completion.
This behaviour is not suitable for just
checking if the chunk is loaded.
While cfeef75cd9 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 cfeef75cd9 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.
When a chunk goes from a ticket level where it is loading a
full chunk to an inactive state (i.e ticket level 33 to
ticket level 45) the full status future will be completed
with a "Right" Either (indicating unloaded). However, this
will also schedule the unload callback immediately.
However, the callback is not immediately executed. This means
the next unload/load callback that needs to be scheduled will
fail. The fix applied is to not schedule a callback if the
chunk is not loaded - if the Either is "right."
Even better, due to how completablefuture works, exceptions
are not printed by default. So the exception thrown by the
callback executor was not printed and the failure
hidden from console. This explains why no-one has tracked this issue.
Now the exception is printed so future failures with the
callback system (if any) can be tracked easier.
Chunk loading logic can make getTileEntity calls, and these can
be off of the main thread (i.e lighting). The TileEntity fixer
makes a getType call, which will block on chunk load. Thus a
deadlock can occur between a lighting thread and the server thread.
