We can't override the getID method in Packet, as it is marked as final.
Instead, we'll just generate a seperate class for each packet ID that
needs to be intercepted.
We can't inherit from the packet ID of any particular class, as it
may get recognized and modified by the sendPacket() method. This could
be a problem if this recogition is necessary, but we'll come back to
this later.
This is done by constructing a proxy around the class after every
event handler has been invoked, intercepting the write method. Each
PacketOutputHandler registered by the packet event listeners is
invoked in turn, modifying a byte array of the data that will be
written to the network stream.
The byte array is initially filled with the serialized version of the
packet in the packet event.
A lot of methods changed from accepting DataInputStream to DataInput,
which messed with the part that dynamically finds the "readPacket"
method. Changed to accepting any method whose signature contains a
parameter derived from DataInput.
In NetworkFieldInjector, we use a "inverted" packet class to undo the
data received counter when a packet has been cancelled.
Previously, we would generate a proxy class that inherits from the
class of the packet (Packet3Chat, etc.) along with its size() method
(which is called and added to the counter, cancelling the other packet),
but this doesn't work for packets that are dynamically sized such as
Packet255KickDisconnect. Instead, we now pass the actual instance to
the proxy class through a weak hash map.
All warnings and error messages will now be identified using fields in
the sender classes, to avoid depending on the format of the error or
warning messages directly. This decoupling will make it possible to
filter out certain irrelevant messages.
Earlier versions of ProtocolLib would in fact load at startup, but due
to an experimental change (ffd920e5b2) -
where ProtocolLib injected code into DedicatedServerConnectionThread in
order to intercept pending connections - the load order had to be
set to world.
This injection was later removed, but the load order was never
reinstated. This causes problems with plugins that load on startup,
but also depend on ProtocolLib as load order trumpts dependency.
This change reintroduces startup load order.
The original intent of catching throwable is to "sandbox" arbitrary
plugin logic and prevent it from ever accidentally killing threads on
the server. A LinkageError due to a missing or old dependency shouldn't
bring down the server, so we secure it by catching all exceptions around
plugin event handlers.
Trouble is, this also catches exceptions such as OutOfMemoryError or
ThreadDead, which assuredly should NOT be caught. The latter case has
even occured in the wild as seen by ticket 45 of TagAPI on BukkitDev.
Minecraft may terminate the reader and writer thread by calling stop(),
and this could occur within the event handler in a plugin. So we should
let ThreadDead go and propagate it to the appropriate handler in
Minecraft.
