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 Jun 9, 2013I have the following problem; it may be a legitimate issue or just a noobish mistake. When I use the following code to send a bed packet to the player, I get a nullPointerException. Here is the code:
-
View User Profile
-
Send Message
Posted Jun 7, 2013@aadnk
I just downloaded Protocol Lib directly on my ssh and it seems to work fine now, FTP must have been messing with it.
-
View User Profile
-
Send Message
Posted Jun 6, 2013@cuddyier
Can you verify the MD5 checksum of the file (md5sum on GNU/Linux, FileVerifier++ on Windows)? It should be 9e418972e0608a55ea3a82d585d3efa8. If not, I'd check if you haven't accidentally used text mode instead of binary mode on your FTP server, assuming you're using FTP. You should also try transferring the JAR file with a different method. Remember to delete the updates folder inside /plugins too.
But I'd recommend you reinstall your JVM version. That might do the trick.
@robmcdonald5
It seems to work fine for me. Are you using Libigot - Heroes is not compatible with your standard CraftBukkit.
-
View User Profile
-
Send Message
Posted Jun 6, 2013Would it be possible if you could add compatibility for the heroes plugin?
-
View User Profile
-
Send Message
Posted Jun 5, 2013@aadnk
Hi
I have multiple servers on the same server box, all my servers but two have protocol lib working fine. I've uploaded the jars the same way for all servers and tried multiple times and checked file sizes, still getting that error after that.
-
View User Profile
-
Send Message
Posted Jun 5, 2013@cuddyier
It might be caused by a corrupt JAR file. Have you tried redownloading ProtocolLib and restarting the server?
Either that, or your JVM version could be to blame. Are you using the latest version? And the 32-bit version, if you're on a 32-bit operating system (Windows)?
-
View User Profile
-
Send Message
Posted Jun 5, 2013Why would I be getting this error? http://pastebin.com/f4B2k3Je On version 2.4.3
-
View User Profile
-
Send Message
Posted Jun 3, 2013@libraryaddict
Well, that's pretty much what I do internally in WrappedDataWatcher. But sure, it might be a tad faster to avoid creating wrappers for reading or writing to the entries in the map.
The only downside (or feature) is that you tie yourself to a specific Bukkit version due to versioned packages, but you do that already. I guess it doesn't matter then, but theoretically you could avoid referencing it altogether.
-
View User Profile
-
Send Message
Posted Jun 3, 2013@aadnk
Actually I used a different fix
https://github.com/libraryaddict/LibsDisguises/commit/bf48c0baac0039fd71c12e2f2ca27c84175a7404
-
View User Profile
-
Send Message
Posted Jun 3, 2013@libraryaddict
Ah, yeah, that's right. I think I've even brushed up with this exact problem myself ...
But you can retrieve and change the DataWatcher with ProtocolLib. Just call getDataWatcherModifier().read(0) and make your modifications then. You may have to clone the data watcher using deepClone(), however. Then, you write it back to the packet, and ProtocolLib will do the rest.
-
View User Profile
-
Send Message
Posted Jun 3, 2013@aadnk
FINALLY.
I think I solved the mystery.
Completely forgot that mob spawn packet is sending a datawatcher as well!
Don't think this is something you would handle.
Now I just need to either prevent it being sent. Send a empty one. Or something ^^
Edit: Solved it by simply doing a 'clone' sort of thing. Basically copy it into a new datawatcher and feed it that.
Thankfully mob spawn packet doesn't want anything fancy from the datawatcher its fed.
-
View User Profile
-
Send Message
Posted Jun 3, 2013@aadnk
Narrowed it down even further.
It has nothing to do with the server itself.
Strangely it seems that its sent double for players.
-
View User Profile
-
Send Message
Posted Jun 2, 2013@aadnk
Entity metadata.
And I was just doing something of my own.
Had the client logging all the values being sent through 18.
It was spammed with duals of
Basically. I think there may be more then just my packet being sent.
As in. Two packets are received.
But I didn't auctally check that the datawatcher is the correct one.
But it seems pretty likely considering it was being spammed and I'm spamming the disguise.
https://github.com/libraryaddict/LibsDisguises - My source btw.
And packet 40 entity metadata doesn't contain that method.
Edit: It rather sounds like I'm sending 2 WatchableObjects at once. So I just checked. But I'm only sending what I expect to be sending.
-
View User Profile
-
Send Message
Posted Jun 2, 2013@libraryaddict
I wonder ... could this be caused by the following in TcpConnection (line 190, MCPC):
Which leads to the following function:
Which again calls:
This appears to cause packets to be dropped if there's a more recent packet of the same packet ID that pertains to the same entity. It's possible that your modified packet gets dropped through that, but I would have to look at the source code of your plugin to be sure.
It's just a hunch, but I think it might be the key. What is the packet ID of the packet that gets dropped? Only certain packets have a containsSameEntityIDAs() defined.
-
View User Profile
-
Send Message
Posted Jun 2, 2013@aadnk
Finally managed to replicate it. I'd setup a scheduler to do something like 10 disguises a second -.-
Anyways. I had the viewing client running through SMProxy and the result?
There is no packets being sent which are obviously wrong.
In short. I don't think ProtocolLib is missing packets. As in. Its catching every single packet and modifying them correctly.
-
View User Profile
-
Send Message
Posted Jun 2, 2013@libraryaddict
You know, you could also try using AspectJ and essentially log all method calls and parameters in ProtocolLib. I did that in a separate branch with this already - you can find it here. You then simply tell the person who can reproduce it to use this debug version, and then send his protocol-lib.log (compressed, preferably).
Note that it currently only tracks method calls in com.comphenix.protocol.injector, but that should be enough to determine if the packet is being intercepted or not, perhaps even showing why.
-
View User Profile
-
Send Message
Posted Jun 1, 2013@aadnk
Huh. As I said. I could replicate this. Then all of a sudden I can no longer reproduce the issue.
As in. I've tried to disguise myself over 300 times. No more crashes. And I'm completely positive I did not change a thing.
So in short. I can no longer reproduce this bug O.o So I'm not really sure this is worth chasing down until someone can reproduce it.
Edit: Turns out the original guy who reported it can still replicate it. *facepalm*
-
View User Profile
-
Send Message
Posted Jun 1, 2013@libraryaddict
I will have to look into this tomorrow - it's almost five in the morning for me, so I should probably head off to bed.
But I would recommend logging the packet stream between the client and the server using something other than ProtocolLib. I remember using SMProxy (or something like it) a while back, and it worked wonders then. That way, you would at least be able to verify your suspicions, and also determine the content of the packet.
I can only think of a couple of reasons why ProtocolLib might miss this packet:
But, there might be something else going on.
-
View User Profile
-
Send Message
Posted Jun 1, 2013@aadnk
Using ProtocolLib for disguises. Everything seems fine.
But I'm getting a issue I just can't track down.
Basically in entity metadata packet. I catch it and modify values inside it so that the clients do not receive a WatchableObject that isn't correct for the entity they are viewing.
But there seems to be a RANDOM chance that it fails. As in a integer is supposed to be a byte. But its still a integer.
I stuck in debug logging and tried to find out exactly what was going on. I also used 'packet add server 40 true'
The result = It all appeared as it should. Packet is modified and so on. While the client crashes.
My last attempt was to see if the WatchableObject's were containing bad objects. Such as a byte when it should be a integer.
But its impossible for me to replicate the issue again -.- The clients were refusing to crash.
I tried going back to the code I was using back when it crashed. No go.
So in the end I think that you might have some chance or somewhat that a modified packet is ignored and the real packet is sent?
https://github.com/libraryaddict/LibsDisguises
The code I'm using is there. And the error the client throws up is the exact same error as when I intentionally prevent it from sending metadata.
And as of this point. I can no longer replicate the issue despite having NO changed code. I even checked it in github to be sure of this.
I changed no plugins etc. There are no other plugins hooking into ProtocolLib either. I'm not using a custom craftbukkit either!
A head bashing frustration.
If you care to try see if you can replicate the issue. Just grab my disguise plugin and try disguise yourself as a enderman. About 20 tries in a row normally has good odds of a crash. You need another client.
-
View User Profile
-
Send Message
Posted May 31, 2013@aadnk
Thank you very much, it's work fine