ProtocolLib

ProtocolLib

Use 3.4.0 for Minecraft 1.7.9/.7.2/1.6.4/1.6.2/1.5.2/1.4.7 and older

Users of MCPC-Plus 1.7.2 and above should look for a special build (ProtocolLib - MCPC 1.7.2) on my Jenkins server. Cauldron users should download ProtocolLib - Cauldron.

Certain tasks are impossible to perform with the standard Bukkit API, and may require working with and even modify Minecraft directly. A common technique is to modify incoming and outgoing packets, or inject custom packets into the stream. This is quite cumbersome to do, however, and most implementations will break as soon as a new version of Minecraft has been released, mostly due to obfuscation.

Critically, different plugins that use this approach may hook into the same classes, with unpredictable outcomes. More than often this causes plugins to crash, but it may also lead to more subtle bugs.

Up-to-date developer builds of this project can be acquired at my Jenkins server. These builds have not been approved by the BukkitDev staff. Use them at your own risk.

Support

Please create a ticket with as much information as possible if you experience a problem that has not already been reported. Comments with a huge stack trace will be deleted.

If you need help with the API, please use the developer support forum. If your question cannot be made public for whatever reason (including security bugs), send me a personal message instead.

For server operators

Just download ProtocolLib from the link above. It doesn't do anything on its own, it simply allows other plugins to function.

FAQ

  • Why do I get FieldAccessExceptions when I try to read or write from packets?
Quote:

The reason for these exceptions is because ProtocolLib is not using the packet format as described on the Wiki, it's using the in-memory representation of these packets. Often, the in-memory representation will use integers instead of shorts and bytes, and store more complex objects (like ItemStacks) directly.

You can figure out the in-memory representation from the Minecraft source code, or just use PacketWrapper where I've done all that work for you.

Examples

Source code for a bunch of example programs that use ProtocolLib can be found at this thread on the main support forum.

You may also be interested in PacketWrapper, a library that makes it possible to modify a packet without having to decompile the Minecraft source code.

Finally, for the more advanced users who want to use ProtocolLib if present, but still fall back on their own packet listening system, I recommend taking a look at this thread. I explain where and how to inject code into CraftBukkit in order to intercept sent and received packets yourself.

Maven repository

If you're using Maven, you'll be able to automatically download the JAR, JavaDoc and associated sources from the following repository:

<repositories>
  <repository>
    <id>comphenix-rep</id>
    <name>Comphenix Repository</name>
    <url>http://repo.comphenix.net/content/groups/public</url>
  </repository>
<!-- And so on -->
</repositories>

This repository contains ProtocolLib, TagHelper and BlockPatcher. You can add any of them as a dependency like so:

<dependencies>
  <dependency>
    <groupId>com.comphenix.protocol</groupId>
    <artifactId>ProtocolLib</artifactId>
    <version>3.1.0</version>
  </dependency>
</dependencies>

Commands

Protocol

Main administrative command. Supports the following sub-commands:

  • config: Reload the configuration file.
  • check: Check for new versions on BukkitDev.
  • update: Check for new versions and automatically download the JAR. The server must be restarted for this to take effect.
  • timings: Toggle measuring the amount of CPU time spent by each plugin. See here for more information.
  • listeners: Display what plugins are using ProtocolLib, and the packet types they are intercepting.

All of these commands require the permission protocol.admin.

Example:

/protocol update

Packet

Add or remove a debug packet listener. This is useful for plugin authors who just wants to see when a packet is sent, and with what content.

Sub commands:

  • add: Add a packet listener with a given packet ID.
  • remove: Remove one or every packet listener with the given packet IDs.
  • names: Print the name of every given packet ID.

Parameters (in order):

  1. Connection side: Either client or server.
  2. Multiple ID ranges: Can be a single packet ID like 14, or a range like 10 - 15. Defaults to 0 - 255 if not specified.
  3. Detailed: If TRUE, prints the full packet content.

Example:

/packet add client 10-13 true

For 3.0.0 and above, you should specify the protocol, sender and name instead:

/packet add play server chat true

In 3.4.0-SNAPSHOT and above, you can also display the packet before its modified by any packet listeners:

/packet add play server chat compare

Remove all listeners:

/packet remove client
/packet remove server

Note that this command should rarely be used on a production server. Listening to too many packets may crash the server.

Filter

The filter system (introduced in 2.4.1) uses the built in JavaScript interpreter in JVM 6 (Rhino) to extend the packet command with filtering capabilities - it is now possible to, say, only print entity metadata packet events (packet add server 40) for a given entity ID:

> packet add server 40 true
Added listener ListeningWhitelist{priority=MONITOR, packets=[40]}
> filter add entity_filter 40
Enter filter program ('}' to complete or CANCEL):
function(event, packet) {
>   return packet.a == 1000; 
>}
Added filter entity_filter.

This should be much more convenient than having to compile a test plugin and reload the whole server. Note that this feature is disabled by default for security reasons. To enable it, add "debug: true" to config.yml.

Configuration

A small set of configuration options are available:

Global section

OptionDefault

Description

auto updater.notifytrueInform any player with the permission protocol.info when a new version of ProtocolLib is out.
auto updater.downloadtrueAutomatically download and install the newest version of ProtocolLib. The installation will take effect when the server restarts.
auto updater.delay43200The number of seconds between each check for a new update.
auto updater.last0This simply records the last time (in seconds since 01.01.1970) an update check was performed. Set it to 0 to force a new update check.
metricstrueIf TRUE, ProtocolLib will publish anonymous usage data to mcstats.org. Set it to FALSE to opt-out.
background compilertrueIf TRUE, ProtocolLib will try and improve performance by replacing reflection with compiled code on-the-fly.
ignore version checkNoneForce ProtocolLib to start for a specified Minecraft version, even if it is incompatible.
suppressed reportsNoneIf any error or warning report is present in this list, they will not appear in the console or the log.

For more information, take a look at the default configuration file.

Tutorial for developers

See this page for more information.

Compatibility

One of the main goals of this project was to achieve maximum compatibility with CraftBukkit. And the end result is quite good - in tests I successfully ran an unmodified ProtocolLib on CraftBukkit 1.8.0, and it should be resilient against future changes. It's likely that I won't have to update ProtocolLib for anything but bug and performance fixes.

How is this possible? It all comes down to reflection in the end. Essentially, no name is hard coded - every field, method and class is deduced by looking at field types, package names or parameter types. It's remarkably consistent across different versions.

Plugins that appear to be compatible

Plugins known to be compatible

  • SpoutPlugin

Plugins using ProtocolLib

Inactive projects

Please let me know if you want me to add your plugin to this list. :)

Privacy

This plugin uses MCStats to generate and publish anonymous aggregate usage statistics, but you can easily opt-out by setting metrics in config.yml to false.

If enabled, the following is sent every ten minutes:

  • Metrics revision version (currently 6).
  • Server's GUID
  • Players currently online (not max player count)
  • Server version string (the same version string you see in /version)
  • Current version of ProtocolLib
  • The name of every plugin that registers a packet listener in ProtocolLib.

Acknowledgements

I would like to thank everyone who has donated to ProtocoLib. I really appreciate it. :)

Donate

Statistics

ProtocolLib Statistics

Note: Create a ticket if you're having problems. Don't post stack traces in the comments.

You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of aadnk aadnk Aug 19, 2014 at 00:22 UTC - 0 likes

    @XzKNIGHTzX: Go

    Mostly, but not all features are supported in 1.2.5, like WrappedServerPing. This is usually documented in the JavaDoc - for instance, every method in PacketContainer that is only for 1.7.2 and above contains the string "1.7.2" in the description.

  • Avatar of XzKNIGHTzX XzKNIGHTzX Aug 17, 2014 at 03:50 UTC - 0 likes

    "Use 3.4.0 for Minecraft 1.7.9/.7.2/1.6.4/1.6.2/1.5.2/1.4.7 and older" Does this mean I can use the 3.4.0 with Minecraft version 1.2.5 as an Api?

    ShadedDiamond Tekkit Classic server ip: shadeddiamond.tk:25703 website: shadeddiamond.enjin.com

  • Avatar of MyPictures MyPictures Aug 07, 2014 at 19:19 UTC - 0 likes

    @asofold: Go

    2 is better then 1!

    BFAK:MyPictures,68804,4095b7e13e1842a5c6922a5b3a9094d1f7dbb5f4e7e36f133280ab58fa2882b0

  • Avatar of MCTylerPVP MCTylerPVP Aug 06, 2014 at 22:19 UTC - 0 likes

    Blue is good right? I'm going to load up your latest build and see how it goes!

    MC Client Link-EODSteven.org- WebPage http://MCTyler.Enjin.com

  • Avatar of asofold asofold Aug 06, 2014 at 21:58 UTC - 0 likes

    @aadnk: Go

    Thanks a lot, so we have some idea what we are doing and what not :9.

    @MyPictures: Go

    It was a special position under "appear to be" - not too bad either :p.

    Last edited Aug 06, 2014 by asofold

    BFAK:asofold,90573112,4305cd44b773216e4e4b4865b3831dcc3c507c15087fb5cfeebd9392050724fc

    NoCheatPlus
    Latest release (1.7.2-1.7.10, approved) NoCheatPlus 3.11.0-RC-sMD5NET-b739
    (Development builds: Jenkins)

  • Avatar of aadnk aadnk Aug 05, 2014 at 01:53 UTC - 1 like

    @MyPictures: Go

    Ah,of course. :)

    I'll add it to the list.

    @Stormbow: Go

    I suppose I could switch to yellow instead:
    http://i.imgur.com/V5RtJCv.png

    Last edited Aug 05, 2014 by aadnk
  • Avatar of Stormbow Stormbow Aug 04, 2014 at 22:15 UTC - 1 like

    Dark Blue text on a black console background, not a good idea.

    bad text is bad

    Please 'Like' my post(s) if I have helped you.
    http://img.photobucket.com/albums/v298/Stormbow/no-trolling.gif
    I would appreciate it very much. :) BFAK:83847,94c9f420badc7fda29227b4adaca49728cacc02e4e890d026ebba529a25877e9

  • Avatar of MyPictures MyPictures Aug 02, 2014 at 23:50 UTC - 0 likes

    @asofold: Go

    Don't forget to tell him that we also want NoCheatPlus in the "Plugins using ProtocolLib" list!

  • Avatar of aadnk aadnk Aug 02, 2014 at 22:31 UTC - 0 likes

    @libraryaddict: Go

    By the way, I think I may have found the reason your listener was executed off the main thread. If a packet is sent by bypassing the normal listeners, every monitor listener will still be notified, but on the same thread as sendServerPacket() is called.

    A very simple solution is to just schedule sendServerPacket() on the main thread if it happens to be called off the main thread, and there are monitor listeners that are not registered with ListenerOption.ASYNC. It could potentially change the order packets are transmitted, but only by delaying them. Hopefully, that won't cause problems.

    Last edited Aug 02, 2014 by aadnk
  • Avatar of aadnk aadnk Aug 02, 2014 at 21:48 UTC - 0 likes

    @XeonG8: Go

    Please upgrade TagAPI to the latest version on BukkitDev.

    @asofold: Go

    The best way to tell if the listener has been executed asynchronously is to call Bukkit.isPrimaryThread(), though as a general rule onPacketSending() will be executed on the main thread and onPacketReceiving() is executed asynchronously (specifically, in a Netty worker thread). Though, if you register the listener with ListenerOptions.ASYNC, the onPacketSending() method may also be executed off the main thread if possible.

    Asynchronous packet listeners are always executed after all the normal listeners have been executed, so no, cancelling the packet in an asynchronous listener will not pass it along to the main-thread listeners.

    Basically, the following listeners is executed when a packet is being sent/received:

    • If a packet is sent by Minecraft, or through sendServerPacket(player, packet, filtered: true):
    • All normal packet listeners in order from ListenerPriority.LOWEST to ListenerPriority.HIGHEST. Listeners of the same priority are executed in insertion order.
    • After that, all listeners of type ListenerPriority.MONITOR is executed, regardless of the value of filtered.
    • Next, every asynchronous listener is executed in their particular worker pools (or the main thread), using the same priority order as the normal listeners.
    • Now the packet is ready to be sent. If any of the listeners have registered an output handler, which transforms the raw packet data being sent, it will be executed now.
    • Finally, the packet has been sent. Any post listeners registered in the network marker is executed in insertion order.

    Yes, it's a bit convoluted. I've been thinking of switching to a Netty-style pipeline, but it's probably too late to change it now.

    Last edited Aug 02, 2014 by aadnk

Facts

Date created
Oct 05, 2012
Category
Last update
Jun 15, 2014
Development stage
Release
Language
  • enUS
License
GNU General Public License version 2 (GPLv2)
Curse link
ProtocolLib
Downloads
1,022,490
Recent files

Authors