It is possible, though not confirmed, that ProtocolLib has not been
fully cleaned up after a "reload" command and the next instance of
ProtocolLib is loaded. In that case, it may be possible that a channel
is injected in the main thread while its cleanup procedure is still
running.
This is an attempt to solve this problem. Though, it is not confirmed
to work.
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().
The current sample code uses the magic packet IDs, which are deprecated in the current version of the library. This commit changes the sample code to use the non-deprecated enum-like packet identifiers, the sample code which is present on the BukkitDev page for this plugin (with some minor tweaks).
Currently, the ClassSource returned by ClassSource.fromMap will return null if the Class cannot be found (as that is the behavior of maps). However, other ClassSources throw a ClassNotFoundException if the class cannot be loaded. This commit changes the behavior of ClassSource.fromMap to throw a ClassNotFoundException if the class was not found in the map (or was mapped to null). This commit also changes the method to interpret a null map as an empty map.
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.
