We also ensure we can run multiple instances of TinyProtocol without
requiring implementers to override getHandlerName().
Also fixed a potential memory leak, as the channel map was set to
weakKeys() instead of the correct weakValues().
This was caused by the fact that "requireInputBuffer" used
findLegacy(int) to get the correct PacketType, instead of
findLegacy(int, Sender.CLIENT). The latter is justified by the fact
that only client-side packets require an input buffer.
The messages incorrectly identified the minecraft server package as "net.mineraft.server"
This commit fixes that
Although it is only a minor spelling error, it is worth fixing
This instructs ProtocolLib to fetch the original state of the packet,
before its processed by any packet listeners above LOWEST. Then,
it displays this state in the console, along with the final state as
retrieved in MONITOR.
NetworkMarker now contains a list of post listeners that are invoked
(in no particular order) when a packet has been serialize and sent
to a player, OR, when it has been enqueued for processing by the
server.
This works for both 1.7.2+ (Netty) and 1.6.4 and earlier, though the
1.6.4 version has a good deal more overhead.
If we update the number, we have to also use the "empty file" trick
to remove the old file, which will crash ProtocolLib on the first
reload. It takes a second reload for it to function at all.
It's much better to take the hit on the version number, and avoid
this issue altogether. The update method simply wasn't designed for
plugins with version numbers in their file name.
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.
