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 Apr 10, 2014@aadnk
Thanks! I could not figure out the new usage of PacketType. I tried to create a new one, but that did not work out! But now I got it. ty
-
View User Profile
-
Send Message
Posted Apr 9, 2014Hi. I am helping one of my friends on a server getting ready for 1.8 and he wanted a way to contact you about the plugin. if possible, email me at albiehoheb94@gmail.com.
-
View User Profile
-
Send Message
Posted Apr 9, 2014@Burglory
I've updated the main tutorial, but it's going to take some time to update all my examples I've written over the years.
It's relatively easy to update everything to the latest API - just change Packets.Server to PacketType.Play.Server (usually) and Packets.Client to PacketType.Play.Client, and it will mostly work. Of course, you can still use the old Packets.Server-enum, but it may case some issues.
@CommodoreAlpha
I mean it doesn't work. At all. It will crash at some point during onLoad(), or even while the plugin class itself is reloading during remapping. That last error seemed to have appeared in the latest version of MCPC, and it seems to be complaining about java.util.Logging. Really strange stuff.
I don't know, it depends on MCPC. I'm hoping the java.util.Logging problem is simply a bug in the remapper and that it will get fixed eventually, but if not, I don't know ... When such basic things as java.util.Logging crash, you're really in for the long run in terms of debugging.
-
View User Profile
-
Send Message
Posted Apr 8, 2014@aadnk
When you say ProtocolLib doesn't work with MCPC+ 1.7, do you mean that it simply does not work with it at all, or that it wasn't built and tested against it and thus could be prone to erratic behaviour?
Also, is there any chance of ProtocolLib becoming "stabler" with MCPC+ in the future?
-
View User Profile
-
Send Message
Posted Apr 8, 2014Could you please update your tutorials? They are all made for older versions and with the API changes, I cant seem to figure out how to do stuff. Thanks! Awesome work!
-
View User Profile
-
Send Message
Posted Apr 7, 2014@libraryaddict
Ah, I see what's going on. Internally, I deduce the correct ConnectionSide for the given list of packet types, which will be ConnectionSide.BOTH for Client and Server packets. The trouble is, this will cause PacketAdapter to register every packet type in BOTH the client and the server whitelist, and thus register a server packet in the client list, and vice versa.
This is a bit of an old warning in any case, and should never be relevant in practive as long as you're not using deprecated APIs. So - I'll just half disable it for now. You can get a version without this warning in build #233 and beyond.
-
View User Profile
-
Send Message
Posted Apr 6, 2014I'm having a new minor problem.
In short. Text is being printed off and I don't know the reasoning.
I'm running spigot 1370 with the latest build of ProtocolLib.
I'm getting this in console.
Where I'm registering these PacketTypes in my listener.
This is what I get when I print off the server packet ID's and Types
http://hastebin.com/magiqibetu.css
And just to elaborate. The code inside is working fine.
-
View User Profile
-
Send Message
Posted Apr 6, 2014@aadnk
No no. Its my fault. Not yours.
My removeDisguise method checked if the entity was alive. If so, then it sent packets to all the players to refresh the disguise.
The people who were using the plugin, when the player died. They removed the disguise..
Then set the health of the players back to 20 so that they didn't see the respawn screen.
Because of that. My disguise plugin assumed those players were dead and didn't bother updating the disguises.
While everyone else saw the entities come back from the dead.
Except. To my disguise plugin. Those entities were not disguised.
So now people could receive invalid packets from the apparently disguised entity.
Basically. It couldn't happen in vanilla which is why no one reported it.
Your plugin worked fine. It was mostly the lack of information as I only caught on to the cause of this bug when I did a game on my server with everyone disguised as a non-living entity.
And people crashed when someone died.
-
View User Profile
-
Send Message
Posted Apr 3, 2014@libraryaddict
Interesting, could you write a step-by-step process detailing how to reproduce it? I tried disguising as a few different kinds of sheep, but that didn't seem to trigger it.
@MisterSanglad
MCPC+ 1.7 is not supported (1.6.4 works, though). The class remapping in MCPC is just too buggy currently.
-
View User Profile
-
Send Message
Posted Apr 3, 2014Hum, I use MCPC+ (1.7) and I had: "[ProtocolLib] [MinecraftReflection] Cannot find standard Minecraft librairy loacation. Assuming MCPC". So how I do ? " Thx for your reply =3
-
View User Profile
-
Send Message
Posted Apr 3, 2014Regarding that old bug I contacted you about.
Entity attributes crashing players as I need to cancel them. Seems the bug still exists.
And it seems I have finally isolated what it is.
When a player dies, I remove the disguise. And some packets slip through..
-
View User Profile
-
Send Message
Posted Apr 1, 2014@bugalugs50
Remember that ProtocolLib is merely a library, and any plugin using could be the real cause of this weird behavior. Your best bet is to list all the suspects with the command protocol listeners, and start disabling until you no longer see the phantom effect (while leaving ProtocoLib running). Then you know which developer to contact.
@baksovic111
Upgrade TagAPI to the latest version on BukkitDev.
@timgeel
Ah, I think I've made the same mistake myself. But it was relatively easy to fix.
-
View User Profile
-
Send Message
Posted Mar 31, 2014Hi, using spigot 175 stable jar, players see their names as phantoms all round them with ProtocolLib loaded. What would cause this? All fine again when plugin disabled.
-
View User Profile
-
Send Message
Posted Mar 31, 2014spigot-1.7.5-R0.1-SNAPSHOT
ProtocolLib-3.3.0-SNAPSHOT or ProtocolLib 3.2.0
Error When entering more than one player
[01:14:29] [Server thread/INFO]: MyName[/IP] logged in with entity id 216 at ([world] 76.5, 65.0, 256.5) [01:14:29] [Server thread/WARN]: com.comphenix.protocol.reflect.FieldAccessException: Field index must be within 0 - count [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.reflect.StructureModifier.read(StructureModifier.java:191) [01:14:29] [Server thread/WARN]: at org.kitteh.tag.handler.ProtocolLibHandler$1.onPacketSending(ProtocolLibHandler.java:54) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.SortedPacketListenerList.invokeSendingListener(SortedPacketListenerList.java:195) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.SortedPacketListenerList.invokePacketSending(SortedPacketListenerList.java:149) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.PacketFilterManager.handlePacket(PacketFilterManager.java:611) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.PacketFilterManager.invokePacketSending(PacketFilterManager.java:587) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.netty.NettyProtocolInjector.packetQueued(NettyProtocolInjector.java:267) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.netty.NettyProtocolInjector.onPacketSending(NettyProtocolInjector.java:235) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.netty.ChannelInjector.processSending(ChannelInjector.java:260) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.netty.ChannelInjector.access$300(ChannelInjector.java:51) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.netty.ChannelInjector$3.handleScheduled(ChannelInjector.java:236) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.netty.ChannelInjector$3.onMessageScheduled(ChannelInjector.java:213) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.netty.ChannelProxy$2.schedulingRunnable(ChannelProxy.java:100) [01:14:29] [Server thread/WARN]: at com.comphenix.protocol.injector.netty.EventLoopProxy.execute(EventLoopProxy.java:76) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.NetworkManager.b(NetworkManager.java:113) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.NetworkManager.handle(NetworkManager.java:91) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.PlayerConnection.sendPacket(PlayerConnection.java:752) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.EntityTrackerEntry.updatePlayer(EntityTrackerEntry.java:323) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.EntityTracker.a(EntityTracker.java:210) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.EntityPlayer.h(EntityPlayer.java:249) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.World.entityJoinedWorld(World.java:1484) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.World.playerJoinedWorld(World.java:1460) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.World.tickEntities(World.java:1329) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.WorldServer.tickEntities(WorldServer.java:515) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.MinecraftServer.v(MinecraftServer.java:676) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.DedicatedServer.v(DedicatedServer.java:273) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.MinecraftServer.u(MinecraftServer.java:566) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.MinecraftServer.run(MinecraftServer.java:472) [01:14:29] [Server thread/WARN]: at net.minecraft.server.v1_7_R2.ThreadServerApplication.run(SourceFile:618) [01:14:29] [Server thread/WARN]: Caused by: java.lang.IndexOutOfBoundsException: Out of bounds [01:14:29] [Server thread/WARN]: ... 29 more
-
View User Profile
-
Send Message
Posted Mar 29, 2014Hello, I found a bug and I private messaged you last night. Can you please read it...
-
View User Profile
-
Send Message
Posted Mar 29, 2014@timgeel
It fixes the problem that hid the original error message. So - see if you can't spot the actual error this time around. It should be caused by a plugin that uses ProtocolLib.
-
View User Profile
-
Send Message
Posted Mar 28, 2014@timgeel
Looks like Apache Commons threw an exception when printing the exception in a packet listener, which bubbled up into LWC Module (among other things).
I can work around this by catching this exception, and printing a warning message instead. Try version #229 on the Jenkins server.
-
View User Profile
-
Send Message
Posted Mar 28, 2014@aadnk
ok thanks you for your answer !
-
View User Profile
-
Send Message
Posted Mar 28, 2014@Stevenpcc
yeah me to, bug since the update for fix the out of bounds
-
View User Profile
-
Send Message
Posted Mar 27, 2014@ZALK851
That has nothing to do with ProtocolLib. You should contact the developer of JSONAPI (Google it) instead.
@gRey83
Sorry, but I have no immediate plans to hack around MCPC+ at this point.
It's causing ProtocolLib to crash on such basic things as java.util.Logging, so who knows what I'd need to do to fix it. If it chocked on NMS calls, that would be one thing - and something I'd expect - but not classes in the JVM. Perhaps I'll look into it once MCPC+ gets a tad more stable.
@Stevenpcc
TagAPI doesn't use ProtocolLib anymore, and it hasn't for some time. You should upgrade to the latest version on BukkitDev.