Skip to content

Instantly share code, notes, and snippets.

@bergerkiller
Created December 18, 2012 17:48
Show Gist options
  • Select an option

  • Save bergerkiller/4330229 to your computer and use it in GitHub Desktop.

Select an option

Save bergerkiller/4330229 to your computer and use it in GitHub Desktop.
Leaving

After several days of testing around, hearing discussions and looking at possibilities, I have decided to stop developing Bukkit plugins. Before I get to the reasoning, here is how I got to the current end-point:

My plugin development history

At the start of 2011 I had an end-assignment for ICT-class to write a 3D dice-gambling game in Java. Me being new to Java, but not new to 3D models and textures, started learning more and more about Java and how to use it. After 5-6 months of working on this, I was finished with my game. It was simple, but it helped me gain insight in how game engines work. It made me understand concepts like a game tick loop, how tick rates alter physics and how to do rendering and sound in general.

During the start of the holidays, I got to know Minecraft. To my surprise, it used the same 3D library I used: LWJGL. At the time I didn't think much of it, but this changed once I started playing online on a friends' server. It was a Bukkit server, and soon enough I discovered the world of plugin development in Bukkit.

I started off with simple things, like IP blocks and chest-trading. Eventually TrainCarts came to be, born from a request thread I found. Later on that year I also made MyWorlds from a previous, unfinished plugin. Then finally all other plugins ended up being made, partially because I needed certain functionality in a plugin or because I found it a nice challenge.

For all that time, development time was a fun time. I could focus fully on making new things and rarely had to look back at old code. This all changed once Minecraft started entering the age of mass updates and my plugins were not excluded. TrainCarts and NoLagg, at the time, required constant attention and this caused a loss of time for new features or improved features. Eventually I got fed up with all these update times, and I started the BKCommonLib library:

1.) Initially it was because the YAML configuration in Bukkit was a serious hassle to work with 2.) Then I started porting over mathematics utilities and material comparisons 3.) Soon enough pretty much everything that was lacking from my 'toolbox' was in BKCommonLib

This went fine...for a while. The amount of updates, both deobfuscation in CraftBukkit and MC itself, reached an all-time high. At one occasion I was just finished fixing up all field references in NoLagg when the next update was already announced...within a week. I found that I could not keep on doing this for all plugins, so all constantly-changing code became part of BKCommonLib.

During the summer of 2012 I found enjoyment in working with Spout and Spout Vanilla, as it allowed me to work on an actual game again. It brought up many memories from my own game project, but not only that, they taught me a lot about things I could've never dreamed of. Everything I know now about the use of interfaces, javadocs, garbage collector, data storage and synchronization I know because of them.

From september to now started my new course (education, I finished highschool in 2011-2012) and I had to spend some time on that. I spent most of my time getting rid of all direct CraftBukkit access and put it into SafeField/Method instances in BKCommonLib. My main goal was to provide a stable environment so I would not have to update my plugins too often. I wanted to prevent having to update too often, because I really wanted to continue working on Vanilla from where I left off.

And nearing completion of this task, Bukkit came up with a fun new idea: "Let's make all package paths of CraftBukkit dynamic!" I knew I could expect horrors, so all I could think of was finding ways to circumvent it. At first, I started eliminating all use of NMS in my plugins. I quickly found that I had already done most of this in the past weeks/months, and there wasn't much left to optimize. All that was left to do was getting rid of the use of NMS World and WorldServer instances and use org.bukkit.World instead. All utility functions in BKCommonLib accepted bukkit classes, but it was still not enough. It was far from enough. Many plugins extended classes provided by CraftBukkit, and I knew that these things can not be fixed or put in a library. My only solutions were:

  • Using reflection and variable-stored classes everywhere, provide wrapper classes for all CB classes in BKCommonLib
  • Altering the class loader to redirect to the right classes (this ended up in byte code editing)
  • Sending my plugins through an external script instead of using a class loader

I managed to do all of the above, and I found that the class loader method was most resilient and also safe. It did exactly what I needed. And then the discussions began. The endless discussions and repeated arguments, lack of listening and lack of understanding. That tiny part of me that wanted to support Bukkit died at that time. I could not stand the unwillingness to understand another's situation.

Bukkit team: I can understand that you are having a hard time keeping it updated. I understand that you want to keep your implementation clean. But you are blaming the wrong people for your problems.

  • People ARE willing to write useful issue tickets, but they are ignored or shoved aside as being a minor issue
  • People ARE willing to improve your software, but you let them wait for months or close PR's without any response
  • People ARE willing to change their code to be secure, but you never mentioned or informed us that this was a requirement

And what do we, the people that ARE willing, get in return? This is what we get shoved on our plate, we, as the NMS core development groups:

  • All your plugins are trash that use code that we discourage. Stop using NMS code. Use the API.
  • You are the problem because admins are running the wrong versions of your plugins
  • We are having too many faulty issues, so now you can deal with them plus an additional 100 per dev related to wrong versions
  • Your plugins are causing severe problems like world corruption. Shows only one example during the entire discussion
  • Your plugins can silently fail, not after this change of ours! (now plugins use reflection and unsafe coding, they will still silently fail)

So it is now, 12/12/2012, that I found that enough is enough.

  • They are now blaming me for admins that make mistakes?
  • They are now completely destroying all the work I put in BKCommonLib of the past 3 months?
  • They are not coming up with solid arguments other than arguments that do not apply to me?
  • Why are they blaming me for things someone did months ago caused by an admin that ran an outdated version?

Even IF they decided to undo the package versioning, I will not return to that unmanaged piece of bytecode they call CraftBukkit. They do not support it. They do not want you to use it. Those that use it are not welcome in the Bukkit community. Who represents me anymore in their Bukkit-API-lover-fanclub? I see no management specifically for CraftBukkit! Where is www.craftbukkit.org? Where can I work on the implementation instead of the API?

Did I seriously end up programming against an unmanaged, unsupported and buggy piece of software? It was so prominent and so stable in the summer of 2011. What happened to those good times one could use CraftBukkit without worrying about version compatibility?

I have had fun times with Bukkit. A lot of fun times. I've helped out a lot of people in plugin development to get them on their way. It was always my pleasure to help someone that could not figure out something. It was always interesting to find solutions to seemingly impossible problems. But those times are over. CraftBukkit is dead, all that remains is the half silver wrapping called Bukkit.

CraftBukkit development is dead and it will not recover. I see no bright future ahead if I continue using it. I find it brave that some tried to tackle this situation, but in the end it is useless. CraftBukkit only had to bridge a period to the Minecraft API. They only had this tiny little goal. Instead, they decided to 'flush the filth' and only leave behind the people that use Bukkit and Bukkit alone.

Those that can not depend on Bukkit alone will have to update until their face is pale from anxiety. I do not want that to happen to me. I also feel sorry for the dev-bukkit team, as they will now have to go into hyperdrive with plugin submission handling. I wish you all good luck with that.

The future

I suspect that all that will remain from this mess called CraftBukkit is Bukkit. Bukkit plugins will be the prominent thing for the next months. This is why I am going to join up Spout to work on BukkitBridge and Vanilla. At least then I have stability to work on new features, instead of compatibility.

I will, when the time is right, port all of my plugins to work on the Spout server. For plugins like NoLagg this may result in the loss of some features, because those are already internal. And I suspect that it won't need NoLagg at all, because honestly, why should there be a plugin to have no lag on a server?

For the plugins I will leave behind: I will not let those die off just like that. I will wait for CraftBukkit 1.4.5 R0.3 and fix up all of my plugins to work exclusively on that build. Any future builds will, and can, no longer be done by me.

After the update session for R0.3 is done I will post a request forum thread where people can respond to continue development where I left off. Until then, I will try to streamline my code so it is easily understandable, something I have already done for the past months anyway. If you are interested in this, just send a PM or wait for me to make that thread.

Anyway, during that period to not expect much response from me, as I'll be busy on many locations simultaneously. I will, however, try to squash any remaining bugs that are too hard to solve for someone that doesn't understand the code.

I wish all of you a Happy Christmas, and for me a whole different new year than last year.

  • Bukkit moderators: Good luck keeping your people in check
  • Bukkit people: Good luck keeping your moderators in check
  • Bukkit developers: Good luck keeping your moderators and people happy

And please, do not be sad, or be fuelled with anger, you have had the past days to do this, and you did. Of course, I was mad too, but there is a point where one just has to let go of things. And for me, it is too much focussing on CraftBukkit, till a point where I barely sleep for 3 hours. This has never happened before, and should be a clear warning to myself that I am harming myself.

Peace out.

Wish to continue my plugins where I left off? See: http://forums.bukkit.org/threads/continuation-seeking-for-plugin-developers-to-continue-my-plugins.117057/

@ttk2
Copy link

ttk2 commented Dec 20, 2012

Take a bow Bergerkiller you more than deserve it.

I remember finding and tinkering with NoLagg on my little server in the kitchen so that I could host 30 players, ah how exciting that moment was. Now here I sit watching a 153 people online, running layer upon layer of optimization and tinkering on a thousand dollar processor and the TPS still hovers around 10.

You fought the good fight, did more than most can even claim to understand, you pushed the limits of Bukkit and with it Minecraft to try and unlock the potential we saw there.

I have stood in your position more times than I can count now, realizing that we are playing Sisyphus with Mojangs little game, its going to be near impossible to replace NoLagg just as an every day tool. But that is all the more reason why I think you're doing the right thing.

If you ever get the urge to see how far you can take a game again, call me up, I have a project you might be interested in.

Otherwise enjoy your vacation, you earned it more than any of us.

@bergerkiller
Copy link
Author

@ttk2
Thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment