FAQ About Plugin Channels

So far I've seen an amazingly good response to my previous announcement, but I've also seen a lot of people with (reasonable!) questions and some thought of their own. I hope to address those here :)

"I'm A Beginner, What Does All This Actually Do?"

Basically, right now the mod community is fairly fractured - there's a huge divide between client mods and server mods, and getting these mods themselves to talk with eachother isn't so simple. We at Bukkit partnered with Mojang to introduce a new official system that should help alleviate the pressure on this, and make things easier for everyone involved. You can now efficiently talk to a client mod from the server, or vice verca, without having to worry about compatibility issues or conflicts or bandwidth or anything like that. It's all so very easy.

If you want this even simpler and a real world example of it all, think of Bukkit server plugins communicating effectively with MCP client mods. Before, this was a pain. Now, it should be very simple :)

What The System Is

The new system is a tool. It's something to use in the background and just forget about it. It's something for mods to implement silently, and it will immediately grant them 100% protection from now until the future against any conflicts on a network level. You're guaranteed that they will never interfere with the client/server if it's running something else, and that other mods will never interfere with your mod in return. You're safe in knowing that it's efficient, and you'll never waste a single byte sending data to someone who doesn't know what to do with it.

What The System Is Not

It's not a replacement for (mod x) - I've seen a few people go "hey (some mod) is better" or "hey this is cool I don't need to switch to (some other mod) anymore". It's something for these mods to use and they'll be all the better for it.

Why Use This When There's Something Better?

There isn't anything better that everyone can agree on. Lots of different mods have their own various techniques and they're not designed to work together. They're also not futureproof and not efficient, relying on unused packets or fields hoping the client will forever ignore the bad values.

With this, you don't have to hack around it anymore. You have a new packet just for modding, and you can do absolutely anything you like through it. I can't think of any reason that's not a good idea.

But What About The REGISTER/UNREGISTER Stuff? Can't I Implement This My Own Way?

While there's nothing stopping you and technically you can, I implore you to reconsider. This system is simple, it's open, it's honest, and it's efficient. It guarantees that both parties know what the other supports and that absolutely nothing will be wasted. If you try to implement it in a different way, you'll "probably" still be compatible as far as not crashing other mods, but you'll be fracturing support again and you won't be able to easily talk to the other side as you would if you were both using the same system.

This system was designed by us and Mojang, not just Bukkit. As far as things go, this is the official way to do it. If you have feedback on how to improve this system more then I'd love to hear it, but let's please not complicate matters from day 1 by making multiple different versions of the same system.

The REGISTER/UNREGISTER stuff is all technically optional and you can just go ahead and send messages regardless, but you'll be wasting a lot of data if you don't. And wasted data in Minecraft doesn't just mean a loss of bandwidth; it's precious processing power on both sides that just can't be afforded when you have hundreds of players on the same server, struggling to keep up as it is.

While it's true that the vanilla client and server right now don't do the registering stuff - that's only because it doesn't support anything, so it has no reason to. I have no doubt that in the future if it decided to support some functionality through this mod packet (Let's pretend "locale requesting", which can be turned off in the client to indicate it won't support it) then that will use the register system as normal.

Bukkit Has No Rights Solving Something That Isn't Their Issue

It's everybody's issue, and this isn't being "solved" by just Bukkit. This is in the vanilla client, it's something that Mojang have helped design and have implemented it as a standard thing. If I ask them to make it read REGISTER/UNREGISTER and do nothing with the value, will that help matters?

It's A Big Waste Of Bandwidth!

It's really not. You only send data if the other side has specifically told you that it supports data. Worst case scenario, you're a client and you support a lot client mods on your server - you'll probably waste 50 bytes as a one time thing for telling the client that you're ok with it sending you data on these channels.

You could potentially reduce this to just 5 bytes or so, by introducing a new channel "1" that gets sent to tell the other side that you support "some" client mods instead of none at all. But perhaps that can be something for the future? It's really not much of an issue right now, at all.

Aside from that registration stuff, no bandwidth at all will be wasted. You can send a whole new mod to the other side for all I care - if the other side doesn't know how to handle that, then your data doesn't actually get sent. 0 bytes wasted.

I Have Another Question

Pray tell - Any common questions I'll add to this blog post! I'll try to reply to as much as I can, too :)


keyname on 01/14/2012 5:32 a.m. #

This feature rocks, and the article is well written. I only have one problem: i cannot say who is the most awesome, Mojang or bukkit. But that is not new.

Johannes on 01/14/2012 12:59 p.m. #

This certainly comes as very welcome news!

I ran a server for a few months, tried various server mods, but it was always a huge pain, especially getting users to correctly modify their client.

After that I swore to not run my own server again until a system was in place that made downloading/using much easier.

Do you think this system will be paired off with a way to have a client automatically install mods a server requires? That would really be ideal.

VoidWhisperer on 01/16/2012 9:23 p.m. #

Is this implemented into MC yet?

dinnerbone on 01/16/2012 9:24 p.m. #

Yes, as of 1.1

Paradox on 01/18/2012 3:44 p.m. #

so, if API already exists in MC1.1, is there any documentation how to use it on client-side? because in bukkit it's clear to understand =)

Cole on 04/05/2012 3:11 a.m. #

Do you have plans to give the server the ability to install mods on the client? With this system you could have a whole chunk of the world missing because a client without the mod tries to connect and there's a marble block or something in the world.

Leave a comment

Comments are now closed for this entry.