insightfowl is a site run by me (Warren Loo AKA EvilSeph) intended to be a look into my personal thoughts on various topics I am passionate about: like games, software, technology and other miscellanea. As an added bonus of being the Team Lead of the Bukkit Project, I am afforded the unique opportunity to provide insight into the way one of the largest Minecraft server mod projects out there functions, as well as the ability to offer my readers an open and powerful avenue for dialogue on how to improve the project for the better. See the Who page for more detailed information.
BukkitLog is a series I'm trialing on behalf of the Bukkit Project to determine if our plugin developers and GitHub contributors will find developer-centric communications useful. Articles will be of variable length and purely directed towards developers. In this particular article, I'm also experimenting with providing ETA-esque information, which is something we've shied away from for good reason.
As I covered in a recent article, I've been pushing the project to release promoted builds more frequently to address a challenge we face from day to day: Minecraft's unpredictable release schedule and ramped up development pace (something I would like to eventually cover in detail in another article). Unfortunately, due to a recent trend of adding new or further complicating old commands to Minecraft, we hit a bit of a snag due to the way we handle commands.
Thankfully, now that we have our new Minecraft command handling in, we're well on our way to a CraftBukkit 1.7.2-R0.3 and future updates will no longer be blocked on the requirement to add commands to Bukkit before they become usable. With our new proposed system, we'll be able to offer Bukkit and Mojang versions of each command, as well as the ability to always use the Mojang version of the command for CommandBlocks.
Following that, we've been working on updating to 1.7.4 and, as such, I'll be placing the project under a (hopefully) short code freeze while we complete that work. Unlike the previous update, I do not foresee any issues arising with our tools that would necessitate the need to hold back the updating of our mc-dev repo. Once the update is completed, I'll lift the code freeze on the project and we'll continue processing PRs as we have recently been doing.
I'm really happy that PRs are moving again and our awesome community is able to contribute directly to the project. Even so, there is still more work for me to do before I am able to get our handling of PRs to an acceptable level of efficiency and efficacy that I will be satisfied with. In the case of this update specifically: I was forced to redirect and focus resources on solving the blocking commands issue mentioned above (and detailed in the previous article), unfortunately resulting in other aspects of the project halting. There is definitely a lot to be said on the challenges we face that have led to our poor PR handling and I hope to be covering this topic in future articles.
Thanks for your continued support and your welcomed patience in this matter. I want to fix our PR handling for good and hope that, once I do, you'll give contributing to Bukkit another go :)
Leave a comment if you've found this communication useful as I’m trying to determine if it is worthwhile to dedicate time and resources into not only this series, but also potentially exploring a more official developer-centric means of communication as a project for Bukkit. BukkitLog should be an extremely powerful tool for communicating important messages to the awesome developers in our community and is something I fully intend on using to notify you of code freeze status, how an update affects you, etc.
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
âś“ Live Streamingâś“ Interactive Chatâś“ Private Showsâś“ HD Quality
Anya is LIVE right now
FREE
Free to watch • No registration required • HD streaming
One of the core concerns we have at Bukkit is trying to provide pure Minecraft vanilla (i.e. unmodified) behaviour out of the box, while providing the Minecraft community with the freedom and ability to create a unique experience for their players on a server by server basis. While we're mostly successful in doing so, our support of Minecraft commands (and what they're capable of) is definitely a sore spot and something I'm not happy with. In particular, I'd like to achieve a state where we can continue to offer server admins the freedom and power they already enjoy thanks to Bukkit but still provide the ability to run all the cool and awesome custom maps the Minecraft community keep churning out.
Better Minecraft Commands Support
Around the time we were deciding how best to handle providing Minecraft commands in CraftBukkit, commands were really simple (often limited to only one function) and our approach made sense. These days, however, Minecraft commands have grown considerably more complex in order to allow for interesting custom maps and innovative game type creation out of the box through the use of command blocks. While this advancement is generally welcomed by the Minecraft community as a whole, Bukkit is in a bit of a strange situation. Generally speaking, any functionality provided by a Minecraft command can usually already be achieved through the use of Bukkit plugins giving us little need to focus on commands.
To address this, I've been debating a potential way of providing server admins with the freedom of choosing to use Bukkit or Minecraft versions on a command by command basis. This would mean that, for example, you could choose to use our more powerful Enchant command that let's you force enchantments at higher levels but also use Minecraft's Give command for custom data support. There are many benefits to this system, ranging from added control over commands to complete removal of the need to wait for us to add a new command to Bukkit before the commands can be utilised. An added bonus is that we might even be able to offer the ability to set specific commands to use the Minecraft version for CommandBlocks, while using the Bukkit version for everything else.
All of this would be configurable through a new commands.yml that combines our improved aliases system with an easy to understand and use command block override system, which I'll detail below. For the majority of server admins that will mostly want to be able to run custom maps, getting command blocks to use Minecraft's commands is a simple matter of compiling a list of commands the custom map uses. For power users, you'll be able to decide what version of each command is used on a command by command basis (and we'll be improving our built in aliases system to support much more functionality you might find useful).
If you're just a server admin looking to run a custom map on Bukkit, all you really need to do is figure out what commands the custom map uses and list them in the command-block-overrides section of the commands.yml. So, if the custom map you're running needs the /summon and /give commands, your commands.yml would look like this:
https://gist.github.com/EvilSeph/8878136
If you just want to have all commands in a command block use the Minecraft version, you can do the following (a * anywhere in the list means all valid commands will use the Minecraft version for command blocks):
https://gist.github.com/EvilSeph/8878162
Regardless of what command mode you choose, you'll have access to every version of each command thanks to the built in fallback system we provide. For every command available (including plugins), we hardcode a fallback into the commands system in anticipation of conflicts. For Bukkit commands, we use the prefix of 'bukkit' (example: /bukkit:time). For plugin commands, we use the prefix of 'pluginname' (example: /scrapbukkit:time). For Minecraft commands, we'll provide a prefix of 'minecraft' (example: /minecraft:time).
Let's take the /give command as an example:
/give - uses the plugin version (or bukkit version if there isn't a plugin that adds one), just like you're familiar with
/bukkit:give - uses the Bukkit version
/minecraft:give - uses the Minecraft version
/scrapbukkit:give - uses the version provided by the ScrapBukkit plugin
This has the added benefit of giving power users finer control over what version of the command (be it plugins, Bukkit or Mojang) each main command calls thanks to our aliases system. For those that are not aware, Bukkit has a built in system for defining aliases for commands and these aliases have final say. If an alias fails to register, for whatever reason, the attempted alias is removed completely from the server. Meaning if /time fails to register, /time will no longer exist.
https://gist.github.com/EvilSeph/8857251
While a lot of servers prefer to hide commands by renaming them through the use of aliases or something similar, the preferred way to control access to a command is through the use of the built in permissions. The reason why this is the preferred is because the only surefire way to protect commands from being used by the wrong individuals is to use the permissions system to deny them access. This is especially the case due to the many failsafes Bukkit provides for command registration, resulting in each command having multiple ways of accessing them.
Once again taking the Give command as an example:
Bukkit commands provide permissions along the lines of bukkit.command.* (for example: bukkit.command.give)
Minecraft commands will also provide internal permissions along the lines of minecraft.command.* (for example: minecraft.command.give)
Plugin commands provide their own system that you'll have to educate yourself on
This new system should mean that we can promote builds faster (as we've been trying to do lately) since one of the basic aspects of Minecraft - its built in commands - should work right away. Although, as with anything we have no control over, we cannot guarantee that commands not provided by us will perform as expected and simply cannot support anything but our own work. That said, switching to Minecraft commands will unfortunately be completely unsupported. On the bright side, introducing this system will help bring us closer to what I'm hoping for us to achieve: supporting custom command block powered maps on Bukkit servers.
CommandBlocks and Custom Minecraft Maps
In the same vein, another aspect of the project I'm not happy with is the unintentional incompatibility with custom maps that make heavy use of CommandBlocks. As we strive to maintain a vanilla Minecraft behaviour and experience out of the box, it's a bit unusual for custom maps to not work in Bukkit and I'd like us to at least try to achieve compatibility if at all possible without compromising the integrity and vision of the project. To that end, we've been investigating the possible causes of these issues and looking into ways to address them.
One of the possible causes we've identified is that our handling of commands and their errors differs slightly from that of Minecraft, leading to unexpected behaviour with CommandBlocks. While we will continue to work towards better or complete compatibility, thankfully the proposed changes to our Minecraft command support detailed above should theoretically address this issue too. As such, until we complete our work on improving custom map compatibility setting commands to "commandblocks" mode might make them work better or without any issues.
The ideal situation would be for both Minecraft and Bukkit versions of all commands to work as expected in CommandBlocks and custom maps without needing any changes by map creators or servers and is something I will have us strive for.
Thanks for the support everyone has shown for insightfowl, I really do appreciate it :)! I apologise for how long it has taken me to post another article, it's a combination of the holidays and feeling under the weather coupled with difficulty sleeping. I hope to amp up the frequency of my articles, but we'll see how things go.
BukkitLog is a series I'm trialing on behalf of the Bukkit Project to determine if our plugin developers and GitHub contributors will find developer-centric communications useful. Articles will be of variable length and purely directed towards developers.
Minecraft 1.7 has been one of the more challenging updates for the Minecraft community to adapt to. I'm not aware of any mod development group that didn't have issues getting their tools to work with the update and Bukkit is certainly no exception. As was probably the case with other groups, a lot of the delay faced with our 1.7 update can be attributed to getting our tools to work to our liking.
In the early days of the project, we were forced to hold back on publishing our mc-dev updates since some projects were stealing our work and claiming it as their own. Thankfully, this is no longer the case and we now try to get mc-dev updates out as soon as possible so our awesome community of developers can help us reach a promoted state faster. Unfortunately with the 1.7 update, we ran into some issues with our tools that we had to solve and it resulted in some confusion as to the state of our build system.
Now that we've completed the audit of our build system and are confident and satisfied with the results of it, we'll be releasing the 1.7 mc-dev update shortly and resume working closely with you guys to add support for the new goodies 1.7 has to offer.
Thanks for your patience and understanding in this matter and I look forward to seeing what you guys come up with once we get most of our 1.7 support in.
Leave a comment if you've found this communication useful as I’m trying to determine if it is worthwhile to dedicate time and resources into not only this series, but also potentially exploring a more official developer-centric means of communication as a project for Bukkit. BukkitLog should be an extremely powerful tool for communicating important messages to the awesome developers in our community and is something I fully intend on using to notify you of code freeze status, how an update affects you, etc.
As part of my plans to reinvent insightfowl I've been meaning to host topical discussions on various (possibly contentious) aspects of the Bukkit project in an effort to improve it and hopefully address the concerns brought up by the community. This is the first of what hopefully will be many articles of this nature in the BukkitImprov series. The first topic of discussion will be the oft misunderstood and contested Unofficial Builds Policy that we've decided to enforce within the Bukkit ecosystem.
This article will cover what the policy is, why it came to be and why we feel that it is necessary, as well as clarify what support we are able and open to provide - and have always been open to providing - to third parties. Due to the nature of this series, these articles are likely to be pretty lengthy and in-depth - you have been warned ;).
What is the Unofficial Builds Policy?
The Unofficial Builds Policy is a blanket ban on the discussion and distribution of any unofficial builds anywhere within the Bukkit ecosystem.
This policy is meant to provide several benefits to the project at the unfortunate cost of a little loss of free speech:
Server Admins are afforded security and peace of mind that any server they find recommended to download within our ecosystem is officially provided by Bukkit, can be ran with confidence and is supported (with the obvious exception of development or special builds)
We're able to provide our community with the focus, resources and attention it deserves when presented with a problem in our product (not including issues caused by plugins, but we generally try to help out in that case anyway). This is only really possible if we're not needlessly allocating resources to supporting someone else's work.
Provides an incentive to users of third party modifications to seek out support from the appropriate location. Although we'd love to be able to help people out with anything and everything, there is simply no way for us to provide any decent help on subject matter we're not at all familiar with and unable to dedicate resources toward.
Why the Unofficial Builds Policy is Necessary
In order to really understand why the Unofficial Builds Policy is a good thing for the project, I need to touch on a challenge we faced (and many large projects eventually end up facing): no matter what your intended focus is when starting your project, as time goes on it is highly likely that your focus will need to shift in answer to the way the project has evolved and grown.
On the surface, it may seem like this shift is insignificant and wouldn't impact how you function as a project but that's unfortunately not the case. In fact, knowing your audience is an integral part of making the right decisions for your project. For example: since Bukkit is no longer purely developer focused, we could no longer just put up a Git log of commits to display what's new in a build we've made available. Instead, I had to address this concern by designing and providing a custom download site (dl.bukkit.org) with our own flavour of changelog presentation. It's difficult for me to understate the importance of understanding how to properly communicate with your audience; server admins are a very different beast than developers and a list of commits would only serve to confuse things. This is just one small example of the many things we had to change and adapt to better serve our new audience, and thus our new focus.
A bigger, more impacting consequence of this challenge is the new found necessity to provide adequate support for server admins using our product. In order to provide proper support, we need to ensure we're completely in touch with our product and able to respond to support queries (formal or not) presented by the people who use what we provide. Personally, I feel that if you're not able to fully support the product you're providing, you should not release it for public consumption unless you state as such when releasing it. Even then, if your project blows up in popularity, you should do the right thing and provide support or pull the product regardless of your preference. Misleading users into thinking that you'll be there to help them when a problem pops up with no intention of actually doing so or expecting others to do so in your stead is a personal red flag for me.
It goes without saying that we can only properly support a product we've worked on ourselves. Armed with intimate knowledge of the way things tick and a list of known behavioural quirks, it's not unusual when we're able to pinpoint the cause of an issue with a small glance at a support request. Despite this, I stubbornly refused to let this knowledge stop me from trying to make the Bukkit project as open and accepting as possible. At first, I was naive to think we could openly support any and all third party modifications, but it quickly became clear that this just wasn't feasible. The sad reality is: the cost of providing support for other projects simply wasn't justified by the benefits we got from doing so. As with many things in life, there is often someone or something that ruins things for everyone.
In Bukkit's case, my vision for openness was dashed by two things: a very real security threat and support fatigue due to supporting projects we were not at all involved in. Early on in the life of the project - around the end of March, 2011 - we were targeted by malicious individuals who thought it was a good idea to "beat" us to a Minecraft update. They planned to do this by creating an ugly protocol hack that would allow updated clients to join a server that hadn't been updated yet. The problem with these protocol hacks is that they never fully work, leading to instability and crashing for the client or the server. Something which successful and competent server admins know will negatively impact the reputation of their server.
While we feel that misleading the community by claiming to have a complete update ready when in fact it is just a horrible protocol hack is in poor taste and disingenuous (a topic I might cover in future discussions/articles), these individuals went even further. Not only did they add code that enabled them to track who was running their hack build, but they also added their names to the version output and joined those servers, misleading server admins into thinking they were a part of the Bukkit team. They then used this "position" to cause mayhem on the affected servers by convincing server admins to give them special access, like op (usually under the guise of needing to debug/test something). If this wasn't bad enough, they decided to further escalate the issue by putting malicious code into the build (which would delete all traces of the server, among other things) and prompting server admins to update. As you can imagine, this is not something we could allow to happen and this unfortunately left me with little choice. I simply had to begin locking down on unofficial builds within Bukkit's ecosystem for the safety of the server admins in our community.
When we were still open to supporting third party modifications, we far too frequently found ourselves spending an unjustified amount of time and resources on matters unrelated to Bukkit. On several occasions we've had to put in a ridiculous 1-3 weeks investigating reported issues, that eventually turned out to be caused by a third party modification and, as such, were issues that didn't even apply to our product. In retrospect, one factor that seemed to contribute to this problem was the stubbornness of the third party modification projects and not so much an issue on the server admin's end. With those same mods refusing to communicate to their users that they were not Bukkit and properly identify themselves as being non-Bukkit, many of the reporters were lead to ignorantly believe that they were running our product (to the point where reporters were adamant that they were running our product and refused to believe otherwise). It is this conscious decision to keep their users in the dark that lead to a lot of wasted time and resources within the Bukkit project as we found ourselves unknowingly providing support for their offerings in their stead.
Despite enduring through these battles because I felt it was for the betterment of the community, it eventually became too much of a drain on the project and we had to cut our losses. Bear in mind that aside from this, due to the nature of the Bukkit project, we already often find ourselves providing unavoidable support for Minecraft and the Minecraft server on top of CraftBukkit, further adding to our support load. As a result, I found myself with no alternative: I had to make the difficult decision of betraying my vision for the project. I immediately set off to create the Unofficial Builds Policy, sadly abandoning my wish for complete openness in the project for what I truly believed was better for the community and our server admins.
Open to Working with Third Parties
As covered in the opening of this article: despite the Unofficial Builds Policy being extremely well-meaning, it is definitely one of the more frequently misunderstood decisions I've made at Bukkit. This is especially the case when it comes to what form of support, if any, Bukkit continues to provide third party projects in light of the policy. Hopefully I can clear this up in this section of the article and I've addressed any other questions you've had about the policy in the lead up.
To put it simply, Bukkit is and has always been open to working with third parties provided they meet a few reasonable requirements:
Third Party Projects need to exercise due diligence when it comes to their impact, if any, on the Bukkit Project.
Third Party Projects need to provide a reasonable amount of support for their product to their users
Third Party Projects need to be open to collaboration.
Third Party Projects need to maintain a respectful relationship with the Bukkit Project.
Due Diligence for Impact to Bukkit:
As a prospective informal partner to the Bukkit Project, if we desire to work together we reasonably expect that certain care will be undertaken to avoid creating an undue and unreasonable increase in Bukkit's work, resource usage and time allotment requirements. This does mean that a project needs to be cognisant of the consequences their actions and decisions have on the project they depend on to exist, but we feel that this is a reasonable expectation for responsibility and only serves to better serve the community.
Examples of actions that could have a negative impact on Bukkit include:
Producing/providing a protocol hack - this increases the support load on our end as people end up reporting the inevitable client/server instability as a bug.
Misleading the community into thinking the protocol hack is a complete and working update - this increases the amount of nonsensical bug reports we get as people believe they're running an actual update and often report issues we've likely already fixed.
Misleading the community into thinking a proper update is out when we haven't released one - this leads server admins to neglect staying on top of our releases (or development builds), resulting in bug reports for issues we've already addressed.
Expectation of Support:
If there is any expectation for support from Bukkit from a Third Party Project, we expect that they are responsibly providing their users with adequate support, accurate knowledge and are vigilant about verifying reports before involving us. As our support load is already relatively high due to our need to support Minecraft and the Minecraft server on top of our product, we simply do not have the resources or time necessary to provide support for non-Bukkit offerings or debunk misinformation.
Examples of irresponsible conduct include:
Misleading users into believing that the product they're offering is an official Bukkit endeavour.
Withholding important information that could influence a user's decision, like the pros and cons of the product provided.
Not providing any support.
Directing their users to report an issue to Bukkit when this should be handled by the project itself.
Refusing to properly identify themselves as a Third Party modification.
Neglecting to communicate the Third Party's dependence on Bukkit and what that entails.
Open to Collaboration:
If a Third Party expects to work with us, they need to also be open to collaboration and the spirit of social coding. In a nutshell, collaboration is a two way street and it is reasonable for Bukkit to expect that the projects we involve ourselves with are open to working towards the success of Bukkit and the benefit of the community. If a Third Party is reluctant to contribute fixes and improvements upstream (back to Bukkit) and/or further believes that any similar improvements upstream makes is a negative, this requirement is not met. Accusing Bukkit of stealing work simply because we have a standard for high quality and thus can take longer to address an issue is in poor taste and not conducive to open collaboration.
Examples of not being open to collaboration include:
Discouraging developers from contributing upstream (back to Bukkit).
Silently fixing an issue and not communicating such to upstream.
Racing to address an issue first to the detriment of quality and/or the community.
Expecting a one-sided relationship where Bukkit puts in all the work without any benefit being given back to the Bukkit project.
Respectful Relationship:
It goes without saying that a respectful relationship is key to effectively working together. As the goal is to coexist and help each other, negative behaviour towards one another only serves to undermine that. As long as a project is open to working with us and maintains a respectful relationship and environment to achieve such, this requirement is met.
Examples of disrespectful behaviour includes:
Attacking or insulting the Bukkit Project and those involved in it.
Allowing or encouraging disruptive behaviour which impacts Bukkit.
Actively working to undermine Bukkit in any way.
Falsely claiming credit for work that Bukkit has done.
If a project meets these requirements, we're definitely open to assisting them with issues appropriately. While we still cannot provide direct support for other projects and their users, we're open to working with responsible projects to address any issues reported to them that they've determined - without a doubt - to be on our end. All qualifying projects need to do is handle their own bug reports and support requests as per usual, then when they come across something they feel is on our end, they simply need to verify this is the case and open a ticket on our bug tracker with the relevant information. Provided the issue falls within the scope of the project, we'll most likely address it - especially if a possible fix is provided with the report.
Thank You!
Thanks for the support you've shown insightfowl so far! I hope you're finding the articles enlightening, interesting and engaging. As the focus of these types of articles is to foster discussion. I'd really appreciate your involvement in the comments section so that we can have a mature, civil and hopefully insightful discussion on this particular topic in order to improve the Bukkit project.
Happy Holidays everyone :)! Just a heads up: I'll most likely be taking a break from everything over the holidays, so there probably won't be any new articles until I get back.
BukkitImprov: Directed Discussions to Improve Bukkit
One of my personal life philosophies is: there is always something to learn from someone else. With over 7 billion people spread out across the entire world, there are many opportunities to learn from the varying and insightful life experiences each unique individual is blessed with. It shouldn't be surprising then that it is also one of the philosophies that permeates through everything I touch and Bukkit is no exception. As a project and as a whole, Bukkit is constructive feedback orientated. Not only do we provide two forums dedicated to gathering such feedback, but a feedback friendly philosophy is also espoused by the entire team all in an effort to always be open to improvement.
While the dedicated feedback forums are definitely useful avenues for discussion that we check frequently, it is less effective for collecting directed feedback on specific topics and a less than neutral location to host discussions. In light of this, I decided to start a new series on insightfowl called BukkitImprov. In a nutshell, BukkitImprov will hopefully be a series of articles focused on different topics for discussion which should assist me with improving the project or at least provide insight into why the Bukkit project functions the way it does.Â
By hosting these discussions on insightfowl, I hope to allow anyone and everyone to get involved in the discussions, especially including individuals that have been banned from the Bukkit community for one reason or another. Provided people remain respectful, civil and mature throughout, I'm hoping to provide an open and welcoming avenue for discussion here. As I personally feel like a lot can be learned from the opinions of someone not deeply invested in the project, I'm fine with taking the risk of giving them an extra chance to respectfully voice their concerns.
So, there you have it. I look forward to the lessons I can learn from everyone and am excited for what it could mean for the future of Bukkit. If you have any feedback on or questions for this series please feel free to leave a comment so that I may address them and improve insightfowl's offerings.
Thank you for the amazing support you've shown for insightfowl so far and I wish you all Happy Holidays! :)
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
âś“ Live Streamingâś“ Interactive Chatâś“ Private Showsâś“ HD Quality
Anya is LIVE right now
FREE
Free to watch • No registration required • HD streaming
BukkitLog is a series I'm trialing on behalf of the Bukkit Project to determine if our plugin developers and GitHub contributors will find developer-centric communications useful. Articles will be of variable length and purely directed towards developers.
The Minecraft 1.7 update has definitely been one of our most involved and complicated updates yet, with most of the Minecraft server's code touched and a large amount of refactoring having taken place. As a result, I decided to place our project under a semi code-freeze, focusing only on ensuring stability, in an effort to build a strong foundation before we began making additions to our code. This is also why we've been prioritising update related and stability-fixing pull requests.
The good news is that, judging by the activity on our bug tracker, we've managed to address many of the stability issues discovered and have begun to slowly thaw out the code to allow for non-critical bug fixes/code additions. What this means for contributors is that we've reached a point where we're relatively happy with the stability of the server and will be looking into PRs that address non-stability-centered issues.
For the plugin developers in our community, this semi code-freeze unfortunately means that we've likely not even begun work on updating the API, so depending on the state of the API is still not recommended. Minecraft 1.7 introduced a lot of new or changed concepts that will likely affect the behaviour of our API and probably result in API breakage.
Leave a comment if you've found this communication useful as I'm trying to determine if it is worthwhile to dedicate time and resources into not only this series, but also potentially exploring a more official developer-centric means of communication as a project for Bukkit. BukkitLog should be an extremely powerful tool for communicating important messages to the awesome developers in our community and is something I fully intend on using to notify you of code freeze status, how an update affects you, etc.
As a large and popular Minecraft server modification, Bukkit is faced with an interesting problem. What started out as a drive to create the quintessential Minecraft plugin development community and project has morphed into more of a consumer-oriented product instead. With this change in dynamic, we are presented with a new challenge: whenever I communicate with the community, I have to now keep the wide and varying audience we have in mind. Simply put, different groups need and respond better to different messages. For example: Server Admins prefer release, update and PSA/security announcements, while Developers are more concerned with API changes, project status and technical write-ups.
Due to the size, presence and purpose of the project, our target audience for articles posted on the front page of bukkit.org tends to be more Server Admins than anything, leaving us without a proper location to communicate developer-centric notices to the Developers in our community. Although GitHub would be the best platform for us to achieve this, unfortunately it doesn't provide us with the facilities to achieve what I want. Ideally, GitHub would have a configurable notice system like the one XenForo provides where I could put up short, useful announcements regarding the state of the project (for example, whether or not we're under a code freeze).
Since this isn't the case, I've decided to trial a dedicated series on insightfowl called "BukkitLog" to hopefully address this. BukkitLog will likely consist of varying length posts communicating the status of the project and Bukkit developer-centric information. I plan to almost immediately take advantage of the newfound freedom and flexibility this series will provide us by posting the first of many BukkitLog communications in the very near future. If this new form of communication is well received, I'll look into putting in resources to get something more official in place.
In the past we've announced planned changes officially without giving the idea a proper trial run, often leading to initiatives publicly falling flat when they don't mesh well with the project. This is one of the reasons why I decided to reinvent insightfowl: it acts as the perfect location to experiment with ideas and have discussions around them and the impact they could have on the project before we needlessly pour official resources into them, on top of being a place for me to share my thoughts.
This is one of the many changes we have in mind and steps we're taking to improve the Bukkit project. Hopefully this explains some of the challenges we face with communication and begins to address some of the issues our fantastic community has with our project. Any feedback you have is extremely welcomed, please feel free to start a discussion in the comments!
Minecraft 1.7 (released October 25th, 2013) introduced a new logging backend known as Log4j2 that provides a refreshing amount of freedom over your logs as a server admin. As a result of this addition, however, the behaviour of Minecraft's server logging has noticeably changed, for better or worse. While some people might actually like the new behaviour, if you who don't you'll be happy to know that you are able to relatively easily get back the old logging style.
This article will be short, sweet and to the point. It will cover the basics of Log4j2 and how you can use that knowledge to revert back to the Minecraft 1.6 logging behaviour, as well as how to reset your logging back to default if you decide it isn't for you. If you're looking for a more advanced article, you'll definitely want to read the next article in this series.
Reverting to Minecraft 1.6 style logging:
If you prefer the old style of logging from Minecraft 1.6, you'll be happy to know that reverting back to it is pretty simple in Minecraft 1.7, thanks to the way Log4j2 works. Due to its design, Log4j2 lets you override Minecraft's built in logging configuration by simply setting a system property, which Java lets you do by passing -D<system property>=<value> when you start up your server.
First thing you need to do is tell your server where your custom logging configuration is located by adding the following to your Java launch line:
-Dlog4j.configurationFile=log4j2.xml
For example:
java -Dlog4j.configurationFile=log4j2.xml -Xmx2G -Xms2G -jar craftbukkit.jar
Now that the server knows where your custom logging configuration is located, all you have to do is create a file called "log4j2.xml" that contains a valid Log4j2 configuration on your server, next to your craftbukkit.jar or minecraft_server.jar. Since you're just looking for a quick way to revert back to Minecraft 1.6's style of logging, I've provided a ready-made configuration for you to copy and paste (with a slightly different version for Bukkit servers due to some changes we make to the server).
Resetting back to Minecraft 1.7 style logging:
Since we have to explicitly tell the server where our custom logging configuration is, it's really simple to revert back to Minecraft 1.7's default logging behaviour. All you have to do is remove the flag you added above.
So this:
java -Dlog4j.configurationFile=log4j2.xml -Xmx2G -Xms2G -jar craftbukkit.jar
Becomes:
java -Xmx2G -Xms2G -jar craftbukkit.jar
For reference (and educational purposes?), I'm including the default configurations here:
Minecraft 1.7 default logging configuration:Â http://goo.gl/lmTT8O
Bukkit 1.7 default logging configuration:Â http://goo.gl/l3LPq5
If, however, you'd like to take advantage of the power of Log4j2 and want some useful insight into what it means for your server, you'll want to read the next article in this series. Once you've grasped the concepts I cover there, you'll be well on your way to making powerful and targeted logs for your consumption as you please.
Please leave a comment to let me know if you've liked this kind of content and would like to see more, or if you'd prefer I cover something else instead. I hope this has provided you with a quick overview as to how to get the old Minecraft 1.6 logging behaviour back and you found this article useful.
When I first started this site (and my blog) last year, I didn't really have anything serious planned; I just thought I would be able to write a post every now and then to satisfy my enjoyment for writing. This time I'd like to take a more serious and dedicated approach to insightfowl, taking full advantage of this unique opportunity to provide you with interesting and insightful discussion on topics of interest.
Along with writing about random topics I am passionate about, I am thankful for the unique opportunity I have to provide intimate insight into the way a large Minecraft server mod project (called Bukkit) functions from day-to-day. To that end, I am hoping to host open discussions about various topics of interest to the Bukkit community in the hopes of improving the project for the benefit of everyone.
Some ideas for topics include:
Our communication during the Bukkit update process.
The Bukkit development process.
The challenges we face as a project.Â
We'll see how things progress and go from there :)
Other topics include:
"Handle" - a series focused on tips for running a successful Bukkit server.Â
Minecraft or Bukkit related topics that hopefully provide you with an opportunity to learn.
"Curious Findings" - a series where I write about interesting and useful software I've found and probably use every day.
Technology, games and gaming (discussion and reviews).
For more information, you should read my About Page: Who (in line with the "Owl" theme of the rest of the site).
So, welcome back to insightfowl! I really hope you enjoy your stay and the stimulating, insightful discussion I plan to host on here. Please feel free to leave a comment to let me know what you think about what I have planned or if you have any ideas for topics you might find it interesting for me to cover and I'll see what I can do :)
Handle: CraftBukkit Best Practises - Part 1, Build Your Server
Handle is what I hope to be a category of posts focused on giving you (often important) information on ways to best get a handle - or control - over the performance and stability of your server. The first series in this category is called "CraftBukkit Best Practises" which I hope will be a 3-4 part series that you'll find useful.
When we set out to design Bukkit, at least from a user point of view, we tried to make it as easy to use as possible, yet many people still seem to have problems getting it to work. The more I think about it, I'm actually okay with this and I wouldn't change how we do things. The fact is: there is more to using Bukkit for your server than Bukkit itself, and if you don't understand the basics of running a server, you're in for a bumpy ride.
It is for this reason that I'm against officially endorsing any modpack, quick installer or 1-click set up package: sure, you'll probably get your server up and running, but will you know how you got it up? How it works? What to do if something goes wrong? No, you won't. The only way you'll know these things is if you take the time to learn how to set the server up yourself. Naturally, it's entirely up to you what you want to do but, at the end of the day, it is my team that has to handle support requests where people are running a huge number of plugins and have no clue which one does what.
For those of you that are consciously running your server, I offer you some "best practise" advice to get the best out of using Bukkit. Still, even if you do currently make use of a mod or plugin pack, or an easy installer perhaps these tips might open your eyes to their flaws and inspire you to educate yourself. Not only would your server benefit from doing so, you might even learn some pretty cool and useful skills that will stick with you for the foreseeable future. Even if you don't fall under this category, this series will offer some key insight into things most server admins should really know, so I suggest you give it a read and subscribe to receive notification of future posts in this series and more.
Build Your Server
One of the most common questions I've gotten from people about Minecraft servers is how to start one and be successful at doing so. Then the next question they ask me is: "what are the best plugins I should be running?" and it is clear to me that they miss the point. Think about this: if your server is the same as every other server out there, what reason do players have to choose yours? By asking for a list of the "best" plugins to run on your server, you're simply recreating the same experience as everyone else and, thus, there is no way to differentiate yourself from other servers.
At the time of writing there are 4,834+ Bukkit plugins available for you to use, with several of them overlapping in functionality. If you truly want to be successful, you need to have an idea in your mind for where you want your server to go before you go shopping for plugins. Not only is it important to pick and choose plugins to stand out, it will benefit you immensely to keep your setup lean by ensuring that you only have plugins you absolutely need on your server. By doing so, you're reducing the cost of maintenance - the amount of your time and energy required to upkeep your server, the headaches you'll have and so on, as well as potentially improving the performance and stability of your server.
Once you have an idea of the kind of server you would like to run, start carefully picking your plugins from the available catalogue. Try to avoid large plugin suites as they're generally inefficient and have much more than what you need and be wary of feature overlap. Remember that with each plugin you add, you are potentially increasing the amount of time and effort it takes to maintain your server: you'll have to be aware of each plugins' updates and bugs, as well as hope that they will continue to be maintained and supported by the plugin author.Â
Designing and building your server is just the beginning, however, if you are aiming for success, chances are high you'll want to try and put together something unique that has your players wanting to come back for more. Think Minecraft Survival Games and Dwarvez vs Zombies - they both have unique, fun and interesting formulas that keep players entertained and wanting more. Coming up with this catchy, successful formula is just one of the challenging parts of running a successful Minecraft server. As a hint, if you look towards the two examples above, you'll hopefully come to the realisation that opting to go the route of developing custom solutions for your server could be a "secret ingredient" of sorts to help you devise that formula.Â
Nonetheless , once you have the formula down, attracting players should be the easiest part of running a successful Minecraft server. Though some might disagree, I am a strong believer that putting your server on a public list is just asking for trouble as you end up attracting the wrong kind of people. Instead, I suggest exposing people to your winning formula and resorting to word of mouth to grow your server. After all, if you have a winning formula, people will be eager to share your server with their friends, and they with theirs and so on and so forth until it snowballs and you run into the wonderful problem of being too popular.Â
Once you've managed to attract players to your server, however, you need to be ready to work to keep them. If you're not careful, running a Minecraft server can easily turn into a full time job: it really takes a significant amount of effort to keep a server up, running smooth and keep your players happy. Not only is it a lot of work but it never ends until you decide to shut down the server. Players can be some of the most demanding goup of individuals out there, especially when their server is down, they've been griefed or they have lost something, or a Mincraft update has come out but your server hasn't updated yet. The list of things that can aggravate a player is ridiculously long and, while I am most definitely not advocating that you let them walk over you, running a server of any kind for any game is often a battle to provide something akin to quality customer support.
Now think back to the start where you were picking 40 plugins to run on your server or you found a handy pack of pre-set up plugins and I hope you realise how impossible it is for you to achieve this. Maintaining your server is a key aspect of keeping your players and if you aren't keeping track of everything doing so will be pretty difficult, which brings me to "knowing your server" which I'll cover in the next post in this series.Â
Feel free to leave a comment below to let me know what you think of this series so far, as well as like and share my posts if you think they're helpful :)
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
âś“ Live Streamingâś“ Interactive Chatâś“ Private Showsâś“ HD Quality
Anya is LIVE right now
FREE
Free to watch • No registration required • HD streaming
Even today there appears to be a misconception about the Bukkit project (or the Bukkit group) prevalent throughout the Minecraft development community: Bukkit is closed-minded; focusing only on server development and ignoring client development, not open to innovation. As the Team Lead for the project, I was faced with making some difficult and often tricky decisions for the project that would set the tone for how we operated and functioned in the future. No one, not even myself, thought we'd still be around a year after the project was started, let alone where we are. Yet we had to make decisions with the assumption that this would be the case, so being short-term focused was not an option.
It's a challenge all leaders face at least once within their 'reign' and arguably one they even face daily or multiple times throughout a day: do you make the easy decision, the popular decision or the right decision? Surprisingly, each has their own merits. The easy decision is quick to enact and usually has the least amount of maintenance associated with it, but it might not provide you with the most benefits. The popular decision wins you the most support (or rather instant support, much like instant gratification) but you run the risk of falling into the trap of being short term focused. That is to say, it might be a good idea right now, but it might not be the best idea for now and the future. Which brings me to the "right" decision. Really, there isn't one. There is only what one could consider the best decision after contemplating all the options and their respective repercussions The best decision is the one that provides you with the most benefits but often at the cost of it being high maintenance or unpopular. Each type of decision has its place in leadership and you're delusional if you think you can be successful by just sticking with one.Â
Leading a project such as Bukkit often requires a lot of juggling. We cater to many different groups of people and it is my job to try and make everyone happy. For example, to ensure the future of the project (so both us and the community could use Bukkit without fear of it suddenly disappearing), I made the decision to work with Mojang, instead of against them as the project and the methods it uses fall into a legal grey area. So, when Mojang decided against client mods, I decided we would respect that stance and focus on server development. Unfortunately, this very public decision has stuck with us well after Mojang changed their minds about client modding, despite it not actually being the opinion of any of the members of the Bukkit team, then or now. While the Bukkit project chose to align its focus with that of Mojang's - we didn't, don't and never did have any objections to client modding and were actually interested in extending Bukkit onto the client before we were given the opportunity to do so officially in and for Minecraft itself.Â
Another difficult and unpopular decision I had to make was regarding the strict code requirements I put in place over the Bukkit project: more specifically and affectionately known as our "minimal diffs" policy. This is definitely what I would consider the "best" or "right" decision. While it could be argued that it stifles innovation (it does), without this policy in place we'd be adding several days on to the update process whenever a Minecraft update is released. Conversely, however, this policy also means we don't have as much freedom as we and others would like to make the changes we want to, often having to resort to a round-about way of doing things or being forced to declare the change out of the scope of the project.
At the end of the day, it doesn't matter. I refuse to make a decision that will significantly negatively affect the project, like increasing the time it takes for us to update, even if this is only possible by sacrificing some freedoms and flexibility that would be nice to have. Secondly, even when there is clear evidence that we've changed our policies, beliefs or our focus, people are still stuck in their ways of blaming us for something we didn't or aren't doing or labeling us incorrectly, letting it impact their opinion of us when, ideally, it should be as if we have begun anew. Lastly, the team might unite behind me and support the decisions I make, but it doesn't necessarily mean that us, as individuals, feel the same way or believe the same thing. It's just one of the many sacrifices we have to make to keep the project successful and alive. The "right" or "best" decision, not the easiest nor, unfortunately the most popular.
One of the reasons why I'm so proud of the Bukkit project and where we are today is that we've managed to retain the high level of quality we set out as a requirement for the project a whole year after we began and we are still going strong. The team goes through many pains and sleepless nights to produce a custom server software that you can have complete faith in running on your production servers once it has hit the Recommended Build stage. This is especially the case during a Minecraft update when the pressure is high to get a working build out as soon as possible so people can check out the new additions in the update and not lose the users on their servers. Unfortunately, this isn't always possible and people get upset.
But it doesn't matter how many emails I get telling me to 'update faster', the limiting factor in our update process is always me: I refuse to release a Recommended Build that we can't stand by. If you wished we released a Bukkit update faster whenever a Minecraft update comes out, we always make our current work available on our download site where you can freely run whatever development build you want. It would be exactly the same thing you'd get if we rushed our "Recommended" Builds out. We go through great lengths (and usually a large checklist) to make sure that when we finally do get a Recommended Build out, you can run it without fear of it damaging your server. One example of a problem we had when working toward a Recommended Build was when we had fire spreading infinitely and un-extinguishable. We were just about to promote a Recommended Build when we ran into invisible fire under water (and random places on land elsewhere) while we were doing a final playtest. I was hoping I could have shared that build to show you how buggy it was but I couldn't find a copy of it (I'll update this post if I do manage to find it). However, that is just one of the many hilarious and scary bugs we've had when developing for Bukkit that we pour hours into making sure you never see.
Unfortunately it is also due to our strict requirements and high expectation for quality that the development of Bukkit moves slower than some people might like. With all eyes on Bukkit, any mistake we make comes back to haunt us - even if those mistakes are only made in development builds. As much as people would like us to just push out experimental changes and hope for the best, we just don't have that freedom and I don't see any other project that faces as much scrutiny as ours retaining that freedom they currently have. We've kicked around the idea of making Bleeding edge builds available to the public - basically builds made by the community through our Bukkit Bleeding initiative - but the situation we're in makes this tricky. As much as we'd like to say we won't and don't support the builds we'd be putting out, it's harder to avoid than most people think. That's not to say this won't happen, it is still an idea we're kicking around, but it might turn into more work than we're really like and we put more than enough time and effort into this hobby of ours as it is.
Still, even I can't deny that things are going slower than I'd like and I'm always looking into ways to improve on the project. For example, we're busy kicking around some ideas for changes we'd like to do to make pull requests move within our development process faster, though time will tell if we do end up going through with them. Nonetheless, we'll never make a decision that sacrifices the level of quality people have come to expect from the Bukkit project. It's one of the reasons why people choose us over everyone else and I'd like to keep that faith and support we've worked hard to garner.
For whatever reason I decided it would be a good idea to start up a blog. I'm hoping to use this site as a place to post rants, interesting information and, hopefully, give people an insight into who I am and how I think. Really, I'm just starting this site up so I can write lots and lots of words since it is something I really enjoy as well as programming.
Thanks for reading :)
insightfowl - inside my mind @ironseph - Tumblr Blog | Tumlook
