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 23, 2013There is some strange problem with mcpc+
[INFO] [ProtocolLib] Unknown origin java.io.DataInputStream@27fd331 for
packet 101
The problem is that i can't reproduce it, only a few users reported it.
And i think mods fakeplayers are the reason.
-
View User Profile
-
Send Message
Posted Jun 23, 2013@ravand
You can build on something like PlayerHider, along with my explicit visibility detector, and stop the server from sending a player's location to the client whenever he or she is out of view.
Of course, you would have to be careful in tuning the visibility detector such that it doesn't overtly tax the server's resources. Perhaps a delay of 5 seconds (configurable) before rechecking visibility?
So yes, I'm pretty sure a plugin could do this using ProtocolLib.
-
View User Profile
-
Send Message
Posted Jun 23, 2013Would it be possible with ProtocolLib to change the way player positions or names are sent to each client? Creating some kind of anti xray for players. There are alot of hack clients that show players with their nameplates from a very far distance destroying the pvp flow
-
View User Profile
-
Send Message
Posted Jun 21, 2013@laacis2
Could you post the full stack trace please (the text that follows what you just posted)? Use pastebin or create a ticket.
-
View User Profile
-
Send Message
Posted Jun 20, 2013attempt to run libigot with lastest protocollib failed.
04:20:01 [SEVERE] java.lang.ClassCastException net.minecraft.server.DedicatedSe
rverConnection cannot be cast to org.spigotmc.MultiplexingServerConnection
Plugins: protocollib
libigot is lastest recommended build, protocollib is lastest build.
-
View User Profile
-
Send Message
Posted Jun 20, 2013@Tritek
Earlier versions of Libigot (build 243 and below) are not compatible with Java 7u25. You need to download and install the latest version of Libigot, or downgrade to an earlier version of Java.
More details here.
-
View User Profile
-
Send Message
Posted Jun 20, 2013@aadnk
-
View User Profile
-
Send Message
Posted Jun 20, 2013@Tritek
Could you post an error report (pastebin or as a ticket) with whatever exception you get in the console?
I'll upgrade to 7u25 and test it myself when I get back home.
@Stevenpcc
Nice. :)
I'll start preparing for the next release then.
-
View User Profile
-
Send Message
Posted Jun 20, 2013@aadnk
I ran my tests again. The new build you linked to doesn't cause a memory leak in Spigot any more. Looks like you fixed it :-)
-
View User Profile
-
Send Message
Posted Jun 20, 2013PLEASE ADD SUPPORT FOR JAVA 7 UPDATE 25
-
View User Profile
-
Send Message
Posted Jun 19, 2013@Stevenpcc
I think I managed to track it down. Turns out I removed the wrong object in a map in the Spigot packet listener implementation, thanks to the fact that the Map interface is not entirely generic.
Give this version a try. If it's works for you, I'll push out a new minor version of ProtocolLib on BukkitDev. This is serious enough to warrant it.
-
View User Profile
-
Send Message
Posted Jun 19, 2013@aadnk
I ran craftbukkit on a minigame server. The memory leak still occurred. I've tested it previously on a live server. It only stopped when I removed the protocollib plugins.
-
View User Profile
-
Send Message
Posted Jun 19, 2013@aadnk
It's a tricky one to track down. I did some testing today, and was able to reproduce it, but only in spigot (latest build), not craftbukkit (1.5.2 recommended build).
This is the code I used: http://pastebin.com/u16rwPjG
You enter and quit the game and it does a world reload. Just keep doing it a dozen times. When it's done without ProtocolLib running there is no leak. When I load the server with the ProtocolLib in the plugins folder, and repeat the process, a leak occurs.
I'll try running craftbukkit on one of my minigame servers and see if the leak still occurs there.
-
View User Profile
-
Send Message
Posted Jun 18, 2013@Stevenpcc
I don't seem to be able to reproduce it myself, perhaps you could make that Barebone plugin if possible?
I installed DisguiseCraft, ItemRenamer and TagAPI (with ProtocoLib 2.4.3) just to be on the safe side, and used Multiverse 2 to generate two extra worlds (test1 and test2) on my test server. After attaching JProfiler, I started using these plugins on all three worlds, and returned to the default world (world). At this stage I verified that the worlds were in memory by creating a heap dump and looking at the biggest objects.
However, after unload test1 and test2, they were nowhere to be found in the heap dump. It didn't leak, as far as I can make out.
-
View User Profile
-
Send Message
Posted Jun 18, 2013ProtocolLib Memory leak
I run a mini game server that loads and unloads worlds to reset them. It suffers from a memory leak, where the world stays loaded in memory, even after I unloaded it. I did lots of testing, narrowing down where the leak was occurring, using jprofiler etc. It seems it only occurs when I use ProtocolLib and a plugin that supports it.
With TagAPI I was able reproduce the leak every time a world was unloaded, simply by having the plugin loaded at startup. With disguisecraft it happened almost every time, with the number of users online seeming to have an impact (a few didn't make it happen, 15 or more it would happen every time). The one thing they have in common is they use protocollib.
I've been going through the ProtocolLib code seeing if I could spot anything that would cause a leak. So far there's nothing obvious. I was just wondering if you'd have any ideas on where to look?
Also, if I were to put together a barebones plugin to reproduce the leak, would this be useful to you?
-
View User Profile
-
Send Message
Posted Jun 17, 2013@ikwerner1
Yeah, it's only used for the "packet filter" command, which should be disabled unless you're running in debug mode.
I'll make ProtocolLib load the engine on demand instead. That way, you won't have to bother with fixing JavaScript support unless you actually need it. Here's the updated development version.
-
View User Profile
-
Send Message
Posted Jun 17, 2013Hi,
I am running the latest recommended build 1.5.2-R1.0 on freebsd. Protocollib higher than 2.3.0 will trow the following error:
Before i installed Rhino this error would be followed by something in the lines of: A javascript engine could not be found falling back to Rhino. Rhino not found.
Can i ignore this warning?
Regards Werner
-
View User Profile
-
Send Message
Posted Jun 12, 2013@romeomax
To quote the main page:
Certain plugins need ProtocolLib to implement features that are otherwise not possible in Bukkit. It's also used to ensure that such plugins don't conflict with each other, as they would otherwise have to patch code on runtime and thus "overwrite" each others patches.
-
View User Profile
-
Send Message
Posted Jun 12, 2013Okay, whats the main point of this plugin?? I have it but i don't remember downloading it. What does this do!?
-
View User Profile
-
Send Message
Posted Jun 9, 2013@Terraquis
I assume you've based your code on this documentation. Unfortunately, this doesn't really apply for ProtocolLib, as you're modifying or reading the internal copy of each packet, not how that packet is compressed and sent through the wire (where integers are often converted to bytes and so on). Instead, you must look at the actual relevant source code, and compare that with the unofficial protocol documentation. I've explained this in more detail here.
However, there's an easier way. Just use PacketWrapper. I've already done what I described above for all the classes, and you can simply copy and paste the classes you need for your project. Use bed in PacketWrapper is here - you'll also need AbstractPacket. Or, you can just look at the source code in PacketWrapper to get a general idea of how to write your code correctly.
EDIT: I forgot to mention, the NullPointException you got is caused by the "null" you've used in line 8. Null is not the same as 0. It's the default value of reference types, and represents nothing or no reference at all (more). You can't store it in a primitive type such as a byte, unlike 0 (zero), which is just a number. But of course, there's no byte variables in the packet in the first place, so it wouldn't have worked even if you passed in 0 as you should have.