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 Mar 17, 2013"Error Unable to uninject logged off player. (java.lang.IllegalArgumentException: key cannot be NULL.) occured in com.comphenix.protocol.injector.PacketFilterManager@1f4d5d1."
Shows up in the chat in-game every so often. Not a very big problem but something doesn't seem right ;)
(Latest version of Protocollib and latest dev build)
-
View User Profile
-
Send Message
Posted Mar 15, 2013@dillyg10
As far as I can tell, things seems to work okay on the very recent development build.
Just give it a try yourself, especially with whatever plugins you're typically using.
-
View User Profile
-
Send Message
Posted Mar 15, 20131.5?
-
View User Profile
-
Send Message
Posted Mar 14, 2013@bergerkiller
No problem. :)
Yeah, that setup sounds fine. Changing to multiple listeners per plugin is also a good change - it simplifies debugging, and I doubt there's much of a performance dip. Only registering and removing is actually slow, as I use a CopyOnWriteArray internally to ensure that everything is thread safe.
-
View User Profile
-
Send Message
Posted Mar 14, 2013@aadnk All right I got BKCommonLib updated to have both a packet listener and packet monitor. I did have to rewrite the ProtocolLib hook, and how packet handlers work in general.
For one, it will now actually register the packet listener/monitor to the plugin it was meant for, instead of BKCommonLib. I also fixed the warning message people had (both ways). I no longer use an adapter extension, I now implement PacketListener directly and create the whitelists myself based on what is possible
Listeners are registered under NORMAL priority, monitors under MONITOR. No issues with this set-up, right?
I'll be testing around a bit more, you can expect it in v1.51 of BKC. Thanks for the MONITOR ignorePacket override btw, it was really needed in multiple places to accurately keep track of certain events.
-
View User Profile
-
Send Message
Posted Mar 14, 2013@Ikadmin
Please submit a ticket instead, along with the full error report and other relevant details.
But first, are you running the latest version of ProtocolLib? It could simply be that you're trying to run ProtocolLib 2.1.0 (or earlier) on the latest Spigot builds, where PL is not compatible.
-
View User Profile
-
Send Message
Posted Mar 13, 2013INTERNAL ERROR: Player hook NETWORK_MANAGER_OBJECT failed.
-
View User Profile
-
Send Message
Posted Mar 13, 2013@aadnk I suspect that the people reporting it are using a different server implementation, having the same issues here...
-
View User Profile
-
Send Message
Posted Mar 12, 2013@Yuri1985
The issue tracker should probably support upvoting ..
In any case, this is a duplicate of ticket 48, and ... I really doesn't look like I'll be able to fix this anytime soon.
The people that seem to report it never respond to my questions, so I can never figure out what they have in common. And I'm unable to reproduce it myself.
-
View User Profile
-
Send Message
Posted Mar 12, 2013@aadnk All right, thanks.
-
View User Profile
-
Send Message
Posted Mar 11, 2013@Yuri1985
You should probably put this in a pastebin and turn it into a support ticket.
-
View User Profile
-
Send Message
Posted Mar 11, 2013@bergerkiller
I've pushed a new developer build where MONITOR listeners can receive "ignored" packets.
-
View User Profile
-
Send Message
Posted Mar 11, 2013@bad339
Nvm, just saw your and bergerkiller's conversation.
-
View User Profile
-
Send Message
Posted Mar 11, 20136:23:59 PM [WARNING] [ProtocolLib] [PacketFilterManager] [BKCommonLib] Unsupported client packet ID in current Minecraft version: 20
Any idea what's wrong?
-
View User Profile
-
Send Message
Posted Mar 11, 2013@bergerkiller
Letting it go through MONITOR is the easiest method. I suppose I could add it.
I should also probably make the cancelled property immutable when executing monitor listeners.
-
View User Profile
-
Send Message
Posted Mar 11, 2013@aadnk Well actually, it makes sense to let 'ignored' packets not go through all listeners. But I think that it should go through monitor, as that one is unable to cancel the packet. Anyone wishing to 'resend' is forced to cancel it, ruling out monitor at all times. Just letting ignored packets (or actually, forced send packets) through the monitor stage should work fine.
It's simply not safe to let some packets 'somehow' make it to the client undetected. Plugins can easily end up in a glitched state this way. For example: keeping track of entity positions becomes impossible, you could be missing packets.
-
View User Profile
-
Send Message
Posted Mar 11, 2013@bergerkiller
Ah, so you want to intercept a packet, even if bypasses the packet listeners.
I probably made a mistake by making it easy to bypass the listeners. Perhaps a different solution would be to specify a subset of listeners to skip instead - probably by a minimum priority (i.e. only pass the packet event to listeners of priority NORMAL or higher), or by some other criteria.
In fact, the main use of this bypass is to avoid a common stack overflow exception (or at least an infinite packet loop) that occurs when a plugin cancels the original packet and send a new one that otherwise would be intercepted by the same packet listener. By sending the packet outside the packet listeners, one avoids processing it again.
But perhaps it would be better if the flag only actually applied to packet listeners registered by the same listener? It wouldn't be too hard to implement, and if a plugin should need to bypass listeners by other plugins, I might add a generic "listener filter" interface to achieve that.
Of course, the majority of servers are still running outdated versions of ProtocolLib (it doesn't usually break), so you would have to check the version number and disable BkCommonLib (or hack around it) if you detect an old version of ProtocolLib.
-
View User Profile
-
Send Message
Posted Mar 11, 2013@aadnk All right thanks, I'll get at it. I have one more question though. How can I (using ProtocolLib) keep track of all packets that actually leave the server? The 'sendPacket' in ProtocolLib allows you to ignore the packet, but I need to keep track of the Packet51MapChunk and Packet56ChunkBulk to see what chunks a player can see.
I need this to optimize the current checks to see whether an update packet (signs) is needed for a player. Since plugins/server implementations tamper a lot with how and what chunks they send, I really need to keep track of this. (be it only because of dynamic view distances and whatnot)
-
View User Profile
-
Send Message
Posted Mar 10, 2013@bergerkiller
Oh, of course. You're using ConnectionSide.BOTH in the PacketAdapter, while packet 20 is only sent by the server. You might want to override the getSendingWhitelist() and getReceivingWhitelist() manually, and only register packets that exists on each side. That's what I do in MonitorAdapter.
The idea behind the warning was simply to gracefully inform the plugin author of a protocol change - if a packet is suddenly server-side only (from previously both client and server side), it's probably time for the plugin to update.
Perhaps not the most ideal solutions, but the alternative is to throw an exception or return a set of the packets which have been registered successfully (which most people would ignore).
-
View User Profile
-
Send Message
Posted Mar 10, 2013@aadnk I'm not sure what that is about, either way it's just a named entity spawn packet, so I am not sure what the message implies. Maybe better if you could explain what the message means and what the reason is that it is happening. BKCommonLib, alone, doesn't register packets, since plugins using BKC do this.