ProtocolLib
ProtocolLib
ProtocolLib has, for the most part, moved over to Spigot! If you need support, head over there!
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.
Links
Support
Please create a issue 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 issue tracker. 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 Maven Central. You can add it as a dependency like so:
<dependencies> <dependency> <groupId>net.dmulloy2</groupId> <artifactId>ProtocolLib</artifactId> <version>5.4.0</version> </dependency> <!-- And so on --> </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):
- Connection side: Either client or server.
- Multiple ID ranges: Can be a single packet ID like 14, or a range like 10 - 15. Defaults to 0 - 255 if not specified.
- 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
| Option | Default |
Description |
|---|---|---|
| auto updater.notify | true | Inform any player with the permission protocol.info when a new version of ProtocolLib is out. |
| auto updater.download | true | Automatically download and install the newest version of ProtocolLib. The installation will take effect when the server restarts. |
| auto updater.delay | 43200 | The number of seconds between each check for a new update. |
| auto updater.last | 0 | This 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. |
| metrics | true | If TRUE, ProtocolLib will publish anonymous usage data to mcstats.org. Set it to FALSE to opt-out. |
| background compiler | true | If TRUE, ProtocolLib will try and improve performance by replacing reflection with compiled code on-the-fly. |
| ignore version check | None | Force ProtocolLib to start for a specified Minecraft version, even if it is incompatible. |
| suppressed reports | None | If 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 Minecraft. And the end result is quite good, 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.
(note that the below list hasn't been updated in ages and ymmv)
Plugins that appear to be compatible
Plugins known to be compatible
- SpoutPlugin
Plugins using ProtocolLib
- Orebfuscator
- TagAPI
- DisguiseCraft
- VanishNoPacket (v3.18.5 and earlier)
- BkCommonLib
- CraftBook
- ChairsReloaded (3.0.2 and earlier)
- Scavenger
- TabAPI
- Individual-Signs
- ItemRenamer
- RandomCoords
- AntiCommandTab
- Sneaky
- Spy
- Statues
- Seasons
- Safe Command Block
- PlayerHider
- Phantasma Chat Filter
- Ghost Hunt
- ReMap
- AttributeHider
- uCars
- uPlanes
- PropHunt
- Portable-Horses
- ClickEdit
- RageBan
- ReChat
- PlayEffect
- FakePlayers
- PlayerCountMessage
- Vampire
- Murder
- NoSpy
- PingNachricht
- NoCheatPlus
- ScoreboardStats
Inactive projects
Please let me know if you want me to add your plugin to this list. :)
Privacy
This plugin uses BStats 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.
Donating
If ProtocolLib has made your life significantly easier or you're feeling particularly generous, consider donating! It's a great way to support the many hours I've spent maintaining this plugin and keeps me motivated. Don't donate if you can't afford it.

I would like to thank everyone who has donated to ProtocoLib on BukkitDev. I really appreciate it. :)
Note: Create an issue if you're having problems. I generally don't check the BukkitDev comments.
-
View User Profile
-
Send Message
Posted Nov 1, 2013@aadnk
That's the crazy thing about this plugin. Its always compatible.
-
View User Profile
-
Send Message
Posted Nov 1, 2013@Quantum64
Yeah, I use reflection extensively, almost to the point of abusing it. But it has enabled ProtocolLib to stay compatible with every version from today and until Beta 1.0 - in fact, I only really hit a snag when the versioned packages were introduced, and I had to slightly break the API by changing the type of PacketContainer.getHandle() from NMS.Packet to Object.
You can see how I inject packets into the stream here. Retrieving a reference to the method itself requires a lot of crazy reflection, as ProtocolLib is also compatible with MCPC (where sendPacket is called addToSendQueue) and other Forge-enabled Bukkit servers. Naturally, it is slower and more complicated than the direct approach, but with a modern JVM the performance is acceptable.
But reflection isn't really a hack in my book. Especially if you compare it to CGLib and ASM, which I use to dynamically extend classes and interfaces, and generate byte code on-the-fly to directly access packet fields without reflection. That's a hack. :P
-
View User Profile
-
Send Message
Posted Nov 1, 2013I've just recently started using ProtocolLib, and I have quick question on how it works. So in the past, i've always had to import really hacky CB code into the plugins (the actual packet classes), and it would break EVERY time a new CB version was released. Then I would use even more really hacky CB code to inject the packet into the stream. It went something like this:
So I was wondering how you actually get and send the packets, I see no actual imports of CB code in your source code, and also ProtocolLib doesn't break on every new build of CB. Does it use reflections or something, or is there just a better way to sent packets than the way I was doing it. (You have to send them somehow right, you can't create a packet sender in a plugin (that would be awesome if you could))
-
View User Profile
-
Send Message
Posted Nov 1, 2013@libraryaddict
You are just incredible. :D
Thanks. :)
And, I think it's high time I added an in-game credit, and made everyone's generosity more publicized. Perhaps a "protocol credits" command, with some fun side effects. :P
-
View User Profile
-
Send Message
Posted Oct 31, 2013Alright. Donated another $200.
Total of $500 now!
-
View User Profile
-
Send Message
Posted Oct 31, 2013@libraryaddict
Ah, now I see what's going on. Wow, I must have been drunk when I wrote the original remove() method ...
It should be fixed now. :)
-
View User Profile
-
Send Message
Posted Oct 31, 2013@aadnk
Tried as you suggested and well. I finally found the problem..
In your onEnable in https://gist.github.com/aadnk/cf76544a658099acbd62
Add another registerListener();
-
View User Profile
-
Send Message
Posted Oct 31, 2013@Shevchikden
Strange, does this occur for every login, or just occasionally?
I would try to reproduce it myself, but MD-5.net is down ... I weren't able to on mcpc-plus-1.5.2-R1.1-forge738-B643, though, so it could be a problem that only manifests during heavy use (concurrency bug or race condition).
@Den_Abr
I don't want ProtocolLib's API to be tied to a specific Minecraft version, so this information has been kept out by design. I compromised on Packets.Server and Packets.Client however, but that did turn out to be a mistake, now that 1.7 has changed every packet ID.
Instead, use PacketWrapper. Just add the classes you need to your project (or use Proguard), and you'll have a easy and fluent API to access each packet.
@libraryaddict
Interesting. I suggest a divide-and-conquer debugging method: first, make a copy of of the plugin. Then, continue to remove code while the problem persists until you're left with the part that's actually causing the problem. Then I might be able to help you.
I do wonder if this is a concurrency bug, though. Are you removing/adding listeners asynchronously? ProtocolLib is supposed to be thread safe, but I might have made a mistake (and I've definitely used too much lock-free code).
-
View User Profile
-
Send Message
Posted Oct 31, 2013@aadnk
Now we have this error :(
http://pastebin.com/j8W0xkqe
-
View User Profile
-
Send Message
Posted Oct 31, 2013It would be cool, if you add enum class with number of packet fields
-
View User Profile
-
Send Message
Posted Oct 30, 2013@aadnk
Yay. After lots of trying out stuff. I think I have a hint.
For some reason, this doesn't work unless its in the original plugin or w/e.
But I added debugging to a packet listener. And everything remained bugged. Then I added the listener to listen to mob spawn packets as well as the metadata packets.
The bug occured again. But this time, the mob spawn packets were still firing debug. The metadata packets were invisible to the listener.
The metadata packets were also listened to by the listener which was disabled.
You may have something wrong in your 'unregister' for the listeners.
TD;DR Unregister listener is disabling another listener listened packets
Something I noticed.
Changing the plugin it listens with, did not change anything. Neither did changing the priority.
-
View User Profile
-
Send Message
Posted Oct 30, 2013@PhanaticD
Do you have the rest of the exception? There should be quite a bit more after ClassCastException at the end.
-
View User Profile
-
Send Message
Posted Oct 30, 2013@Shevchikden
I think I finally manged to track down and fix the problem - it's basically caused by a difference in what kind of packets can be transmitted during the login process. :)
You can find the updated version here.
@libraryaddict
Very strange - I weren't able to reproduce the problem with a simple plugin either.
I'm sure you've already triple checked that unregisterListener() doesn't end up being called for both listeners, so there must be something wrong in ProtocolLib.
Perhaps the packet listeners actually share the same instance? It's unlikely (non-standard JVM), but it might be worth a shot.
-
View User Profile
-
Send Message
Posted Oct 30, 2013i dont know if you are supporting the hacky version or not but i get this http://pastebin.com/euNB6pqu and half the server crashes
-
View User Profile
-
Send Message
Posted Oct 29, 2013http://paste.md-5.net/hepowumadi.java
I'm having a problem with this.
Ghost and DeathGod both use a PacketListener which has identical code.
When either one has unregisterListener called. The other one seems to 'silently call' as well.
This is reinforced by the fact that commenting out one of the removePacketListener in either class has the plugin working as it should.
When adding and removing the packet listeners, checking the registered listeners contain said packet listener shows what is expected. Aka, false for adding, true for removing.
The entire thing that is wrong with the entire code is.
The moment I call the unregister method with either class. It acts as if the other class had silently called the method as well.
Debug output in the abilitymanager acts as expected. Debug output in the register and unregister methods act as expected.
Mainly Thread.dump(); and looking over it.
Do you happen to know what is happening?
-
View User Profile
-
Send Message
Posted Oct 28, 2013@aadnk
That helped a little, but we still get unknown origin error for packet 250 at normal player login. This is how connection to mcpc+ server looks like in logs [WARNING] [ProtocolLib] [ProxyPacketInjector] Unknown origin java.io.DataInputStream@25ac8627 for packet 250. 18:04:41 [INFO] _Shevchik_[/193.218.181.33:61871] logged in with entity id 852 at ([world] 309.3435736702113, 69.0, 535.6691383586965) 18:04:41 [INFO] Loading Player: _Shevchik_ 18:04:41 [INFO] Sending serverside check to: _Shevchik_
-
View User Profile
-
Send Message
Posted Oct 28, 2013@Shevchikden
I guess I could ignore players whose playerConnection is NULL. That should only apply to logged out players, or these fake players in MCPC.
Give this version a shot, and let me know if it improves the situation.
@zaino60
Use the experimental Spigot-compatible version, found here.
-
View User Profile
-
Send Message
Posted Oct 28, 2013please update to 1.7!! It crashes my server in 1.7, i was forced to temp. remove it!
-
View User Profile
-
Send Message
Posted Oct 28, 2013ME again.
Looks like i figured out the reason why mcpc+ fakeplayers lags server and produces errors. It's because of fake player login. I think we need an exclusion list.
Here is the error http://pastebin.com/XTGmm6ig
-
View User Profile
-
Send Message
Posted Oct 27, 2013@storm345
That can't be right. Have you downloaded ProtocolLib from BukkitDev? And what version/flavor of CraftBukkit are you using? Spigot? SportBukkit?