Fetching Packets

Discussion in 'Plugin Development' started by mncat77, Apr 11, 2013.

Thread Status:
Not open for further replies.
  1. Offline

    Rprrr

    It certainly is not easy.
     
  2. I know, but there should be a way as it's possible with Comphenix ProtocolLib. I don't know how the PlayerInjection works and I don't even know if that the key to getting when a player sent a packet, though I'd like to achieve the same with a little less code. If not possible I'll have to use ProtocolLib.
     
  3. Offline

    Comphenix

    I wouldn't think think it was such a problem depending on ProtocolLib - it is after all fairly common these days, and it is designed to be compatible with as many server versions (Beta 1.0.0 up to Minecraft 1.5.1) and forks (MCPC/Tekkit, Spigot, etc.) as possible.

    But if you still want to make your own version, I'd recommend reading this post detailing the different techniques. Keep in mind that you risk conflicting with other plugins if you do this yourself, so I recommend falling back on using ProtocolLib if it is installed. This is basically what DisguiseCraft and Orebfuscator, among others, are doing.

    If you're targeting a recent build of Spigot, you can also use its internal PacketListener. This is essentially what I use in ProtocolLib (and what bergerkiller uses in BkCommonLib), though again, it will only work for Spigot.
     
    mncat77 likes this.
  4. Offline

    bergerkiller

    I truly recommend using ProtocolLib made by Comphenix above. So far, his library has provided the best and most stable support, plus it keeps stuff compatible everywhere. There is a reason I have it supported in BKC :)

    I also have a packet handler implementation in BKCommonLib, but it is less durable and more made 'just' to do the job. It doesn't have compatibility with other plugins in mind at all, so that is where ProtocolLib jumps in.

    If you can: Avoid inserting your own PlayerConnection hooks as primary implementation, let (your) libraries deal with this. There are many plugins that do this already, and they automatically turn those plugins into incompatible hulls. I do detect these incompatibilities and force people to install ProtocolLib in those cases - it is a great way to bring sanity into the packet world.

    mncat77
    Mind explaining why you don't like depending on huge 'libraries'? Because Bukkit is the biggest library of them all. I don't want to sound rude, but deal with it. Big libraries > Small incompatibility-prone implementations. There is a reason many people are using it.
     
  5. I think I'll go with ProtocolLib then....

    bergerkiller
    Such a huge library seemed a little overkill for handling one little subpacket in my opinion and it wouldn't cause any interfearance with any exsisting plugins at this time from what I have searched and if it would interfear with a plugin it'd be a plugin with the exact same functionality as mine and there would be no unwanted errors but just the kicking in of one of them.
     
  6. Offline

    bergerkiller

    mncat77
    Well there you are wrong, because you will have to replace the Player Connection. This means ANY OTHER PLUGIN, including libraries, that do the same, will start having bugs or silently fail. When only your plugin is on the server, you won't notice a thing. This changes once you start distributing it.

    I replace the PlayerConnection too - but in addition check for failure, incompatibilities, and ALWAYS use ProtocolLib instead if it is found. So far, this has helped, as I've had no complaints of failing plugins when used with BKCommonLib.
     
    Comphenix likes this.
Thread Status:
Not open for further replies.

Share This Page