A special-case occurs when a plugin sends a packet to a client
with filters set to FALSE (that is, bypassing most packet listeners) -
a new packet event is constructed solely for all MONITOR listeners, as
they are informed regardless of the value of FILTER.
Unfortunately, the sending method may be invoked on a thread other
than the main thread, which will invoke onPacketSending()
asynchronously. This violate the assumed thread affinity of
onPacketSending(), so we will now schedule the packet sending on
the main thread to correct this - but only if there are monitor
listeners, and they have not specified ListenerOptions.ASYNC (which
means onPacketSending() is thread safe).
We now accept any string in this constructor, to preserve
backwards compatibility. But, we depreciate its use, as
WrappedGameProfile(UUID, String) can be used in every Minecraft
version that supports a game profile.
There's also a new warning system that will identify the plugin
that is using the depreciated method, and print its name to the
console (at most once every hour).
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.
