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
Development builds of ProtocolLib can be found here: https://ci.dmulloy2.net/job/ProtocolLib/
These builds have not been approved by the BukkitDev staff. Use them at your own risk.
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 the following repository:
<repositories> <repository> <id>dmulloy2-repo</id> <url>https://repo.dmulloy2.net/content/groups/public/</url> </repository> <!-- And so on --> </repositories>
You can add it as a dependency like so:
<dependencies> <dependency> <groupId>com.comphenix.protocol</groupId> <artifactId>ProtocolLib</artifactId> <version>4.5.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.
@Scrayos
Thanks for the kind words. :)
You're right, a server crash is far from the worst that could happen. That being said, stability is one of the primary goals of this project. After all, it's supposed to alleviate compatibility issues when multiple plugins inject into internal code, so it better be rock stable itself.
There is another cause for this problem, beside the auto-update feature. Essentially, due to a recent commit in the development build, plugins will have to alter the way they access the internal code and make it version-aware.
Now, certain parts of my API returns a reference to the underlying internal class, which was just added (unwisely) as a kind of last resort if plugins can't use my wrapper, but this completely clashes with the aforementioned commit. Unfortunately, this left me no choice but to break the API in ProtocolLib.
Hopefully, things should stabilize soon.
And for those that have followed the debate that has been raging in the comments; yes, I did reach out to staff members regarding the future of ProtocolLib, and all I can say is that it's still being discussed. Rewriting ProtocolLib is not impossible, but it will take time and it might negatively affect performance. Though, it's still too early to tell.
@aadnk
You're doin' a great Job. I like your Lib very much. It's fantasticle. I got this Console-Spams too, but I downgraded, turned the AutoUpdate to false, and all was working again. So why are those poeple flaming? -
Don't care about'em addnk.
@Escox
It's because you're using an outdated version of Orebfuscator. Please upgrade to 1.7.9.
@Nickbbeezy
I don't think you're using TagAPI 1.8 actually. Try downloading it again.
Why do i get this?
Getting this error with PL 1.8.1 & TagAPI 1.8 http://pastebin.com/Q2tKPnSz
@aadnk
Theres no need to apologize, thanks for the fix
Orebfuscator has now released a new version (1.7.8) fixing this issue. It will also be available on BukkitDev soon. Note that it hasn't yet been fully tested by the community, so you should take some precautions before installing it.
For ProtocolLib, I've added anti-spam protection to prevent this from ever occurring again in the future. You can get it on my webpage (as GitHub's download page has been depreciated).
Wow at all the rage. Someone does all this work to help you and you rage back in his face. These people should have gone through the config the first time they added Protocollib. Calm down and realize this developer is only trying to help all of you and you don't even give anything back to him.
@HitmanPL47
@Intangir
@ms0244412
I can only apologize.
While I should have caught the Orebfuscator problem sooner, and for that reason alone delayed the weekly release, it would never have been a serious problem if it weren't for the idiotic automatic update.
I have already changed it to opt-in for now, but I may remove it entirely. At the very least, auto updates should only occur for minor updates, and even then it's a big risk.
This "feature" can be disabled in many ways, but the easiest is to set "download" to FALSE in the configuration. After that, it should be safe to downgrade to ProtocolLib 1.7.1. I've also added a section above explaining the different configuration options.
Finally, I added anti-spam protection for plugins that break in packet listeners. They will now never print more than 20 error messages consequently, and after that only ever so often. ProtocolLib should never spam the console because of a faulty plugin.
Major Console Spam with 1.8.0
this addon auto updated itself and is now spamming my console with billions of crap
why is this even on? how stupid of a feature is that..
this is going to ruin practically every server that it is running on that auto restarts
it was making mega huge log files full of crap within seconds.. and i was watching it.. it will probably cap out peoples disk usage
that auto update feature should be DISABLED
Thanks for the default setting of auto updates in this great time of instability.. (sarcastic, if you couldn't tell.)
I've released 1.8.0 of ProtocolLib now, in anticipation of the next CraftBukkit release. You will have to upgrade to 1.8.0 when CB 1.4.5R3.0 is finally out.
You can get it now on GitHub, or wait a day for it to be available on BukkitDev:
@Bobacadodl
You're more than welcome. :)
I haven't really advertised it much, but the donate button is on the top to the right, just above the search bar. But I suppose I could add a link that's a bit more visible.
I'm still amazed that anyone would be so kind to donate, so I'll be sure to pass on the generous spirit. :)
@aadnk
Thank you SO MUCH for this plugin! It has an endless amount of capabilities which I previously thought were impossible. What email can I donate to?
@NegroBob
If you use the development version of Craftbukkit, you will have to (at least) do the same for every plugin you're using.
CraftBukkit recently broke a ton of plugins that rely on internal code (NMS and CraftBukkit internals), which all has to be updated. The development version should work though, but it's not fully tested:
You may consider downgrading CraftBukkit instead, especially if you are using other plugins that also broke.
Latest version wont even load
@ZwingGX
Well, the memory leak in the previous version should be fixed, so it might just be that there's too many classes loaded by plugins, and the server can't handle reloads (if you've used it previously).
I'd recommend increasing the perm gen space:
That will increase the amount of memory allocated for loaded classes from 64 MB to 256 MB.
You can also try enabling garbage collection of unused classes, and see if that helps:
Note that CMSPermGenSweepingEnabled is not necessary in Java 1.6 and higher.
@aadnk
i use 1.7.0 also 1.7.1 test
server bat: http://dev.bukkit.org/paste/6667/
@ZwingGX
What version are you running? That problem should be fixed in 1.5.0 and above.