This was necessitated by two new NMS changes:
* NBTCompressedStreamTools.a(DataInput, int) now includes an additional
parameter NBTReadLimiter
* GameProfile changed the type of getId() from String to UUID, along
with the constructor (String, String) to (UUID, String).
We don't want to crash plugins over this, since it doesn't
automatically cause problems. But it may trip up plugins that
assume the packet types they set when registering a listener is the
only ones they'll ever recieve in the method body, which is not true
if a preceeding packet listener can change a packet to an arbitrary
type.
I'm open for better suggestions here. But for now, I'll just print a
warning and hope people use sendServerPacket() instead.
In 659f01cc63, I attempted to
execute packet listeners for receiveClientPacket() on the channel
thread, inadvertently causing them to be executed regardless if
filtered was FALSE, and twice if it is TRUE.
Since asynchronous packet listeners use this feature to take out
packets from the packet stream, they wound up causing an infinite
packet loop. This prevented them from ever being received by the
server.
An example of a dual side packet is Packet101CloseWindow, which is
sent by the server when it forces a inventory window to close, or
by the client to the server when the player voluntarily closes it.
The bug prevented the client-side of a dual side packet from being
recognized in 1.6.4. Thanks to Shevchikden for discovering the bug,
and finding the correct build number where it was introduced.
It's another lazy initialization problem. I only check a single
field before initializing two related fields, which can cause
problems when two threads execute handleLogin() concurrently.
If thread A detects that PACKET_LOGIN_CLIENT is null, it updates both
it and LOGIN_GAME_PROFILE. However, thread B may only see the
PACKET_LOGIN_CLIENT update, and still believe LOGIN_GAME_PROFILE is
NULL. Hence why it causes a NullPointerException in issue #39.
Constructing a WrappedWatchableObject with a
net.minecraft.server.ItemStack would cause ProtocolLib to throw an
IllegalArgumentException, even though WrappedWatchableObject.
setValue(Object) accepts ItemStacks without trouble.
This is because WrappedWatchableObject.getUnwrappedType() didn't handle
ItemStacks at all.
