You can find compiled versions (and a link to the source) on the MC forums.

But it’s never bad to think ahead! With the recent news that the core Bukkit team has been absorbed by Mojang and that Bukkit in its current form is going away, that presents a number of issues for people who currently depend on this ecosystem. Fortunately, in regards to WorldEdit or WorldGuard, the news is mostly positive. We’re hoping to keep everything that you depend on the same as you’ve always been used to, even if mod APIs come and go, freeing up time so you can tend to better things. To us, a deprecation of time of “3 months” is nothing when you’ve got other things on your plate.

We’ve been able to do this because of a few decisions that were made from the beginning. I made a few assumptions going forward in late 2010:

1. One day, the server mod APIs that I were depending on were going to die.
2. It wasn’t really within my means to start my own server mod, due to my future time constraints, and the project would be in a particular crossroads if the project ever needed to enter into a more official capacity.

For better or worse, these assumptions have held uncannily true. It was within a few months that hMod effectively folded, and it is now true Bukkit will be ceasing to exist within a few months’ time. Already, you can find WorldEdit for several platforms, including officially for single player, Bukkit, Spout, unofficially for Canary, at at one time officially for hMod. This means WorldEdit will continue to exist in its current form, for the most part, in whichever new fangled API gains popularity. The process of porting WorldEdit only requires writing a few files of code, a task that takes one or two hours, and it is the reason that WorldEdit was the first mod ported to Bukkit.

Better news is ahead, however. Within the next one or two major versions of WorldEdit, we should have far superior support for custom blocks and entities, allowing you to copy your complex RedPower contraptions or your extremely detailed BuildCraft operation between chunks or worlds. We will also hopefully allow WorldEdit to better handle large operations, performing them in smaller chunks (which currently presents a number of technical difficulties) rather than freezing the game. Scripting support should be improved, and we plan to add better support for better API interaction with WorldEdit, allowing you to more easily modify WorldEdit with new commands or functions that tap into WorldEdit’s vast library and cross-platform support.

As for WorldGuard, many of the ideas were applied. The core potions of WorldGuard are written to be easily ported, though due to the nature of WorldGuard, parts do have to be rewritten for it to be ported.

You do not have to make any changes to your configuration, except in the case of CommandBook if you are moving from an old version of CommandBook (from the days of the customizer).

EDIT: If you have free time, please help test WorldGuard by updating this spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AocVHzayvfjAdHRhcmV4QU5LYjBpdjdJTWNCSlJqRnc#gid=0

1. If you are getting a ton of errors in Minecraft 1.2 for WorldGuard, it is because you need to update WorldGuard (and WorldEdit) to the nightly version linked above.
2. If you are still on MC 1.1, note that we do not currently immediately support MC 1.1 as our hands are currently tied in regards to time.
3. If operators automatically get put into god mode on join, please disable the feature in CommandBook and WorldGuard in config.yml. Future versions should have this setting disabled by default, as it was before.
4. If some things are acting odd (monsters don’t spawn properly, leaves don’t dissipate, crops don’t grow, etc.), make sure you update CraftBukkit.

There are some issues that have been reported but are presently unconfirmed. Please see the previous post for a list.

Unfortunately this update has had possibly the worst timing for us ever, and much of the work is going to waste as Bukkit will be obsoleted within a few months. Nevertheless, we will be hopefully be releasing a stable version this week.

The following are alpha builds of WorldEdit and WorldGuard that are compatible with Minecraft 1.2. While there have been no major issues reported with the releases below, THESE VERSIONS ARE NOT GUARANTEED TO BE STABLE. If possible, please test all features that you depend on, preferably on a test server on your local computer or elsewhere, and remember to check back when an official stable version is released for MC 1.2.

EDIT: New versions are available. See the new blog post.

Recently fixed issues or issues fixed since versions for MC1.1:

• FIXED: WorldGuard: NullPointerException errors when pumpkin scuba is on
• FIXED: WorldGuard: NullPointerException errors when infinite item stack removal is on
• FIXED: WorldGuard: Region flags not working at all
• FIXED: WorldGuard: Chest access being blocked completely
• FIXED: WorldGuard: Becoming invincible on join by default (you must now turn this off manually in the configuration as well)
• FIXED: WorldEdit: World height limitations
• FIXED: WorldEdit: Missing 1.2 blocks and items
• FIXED: WorldEdit: Errors when pasting schematics in some cases

Reported, but unconfirmed, issues:

• WorldGuard: PvP flag does not work
• WorldGuard: Entry/exit member groups flag does not work
• WorldGuard: Invincible flag may not work
• WorldGuard: Block break notification in the blacklist only prints to console
• WorldGuard: Minecarts can’t be broken
• WorldEdit: Jungle trees are not properly regenerated with //regen
• WorldEdit: While the height limit was abolished, it always goes up to 256 even if set at a height limit below 256

If you find any errors, please report them by commenting on this post.

You can follow me on Twitter if you want more up-to-the-minute news. In addition, you are invited to visit us on IRC by joining #worldedit or #worldguard on irc.esper.net.

Please note that we generally do not commit to stable builds until CraftBukkit releases its own stable build.

http://build.sk89q.com

We’ve squashed a number of issues, particular with WorldGuard, just in the past few hours.

1. For my component loading framework, quite a few people have contacted me about their attempts at re-implementing it. zml2008 has implemented one version in CommandBook. I don’t know the details of it, but I assume it’s fairly similar to mine.
2. For my event handling framework, a number of people also told me about their work, but you can find a relatively new implementation of my event system in Bukkit, written by zml2008. It uses annotations as described in my system.
3. For my command handling framework, that can be found in WorldEdit. I have to admit that this code is around a year old, but it performs fairly well, and it’s the exact same one I use in my framework.
4. For my permissions framework, which I didn’t really touch on in the post, at least it lives in the form of perm.issions.nodes, which is something I proposed in January 2011 (Nijiko-kun then wrote the Permissions plugin after he read what I wrote on IRC, many other people wrote later similar versions, and now Bukkit has a different built-in framework). However, if you want to link commands and permissions, you can do that either via WorldEdit’s command handler or via Bukkit’s plugin.yml.
5. For my configuration system, which I don’t think I really mentioned, I am not aware of any implementation of that (then again, I didn’t go deep into it). The configuration in Bukkit is also based off of my previous work, but it’s not as streamlined as in my framework.

So while I definitely haven’t posted a lot of my code, many other people have already implemented a lot of my ideas, so it’s possible to gather the above work into one single framework if you’re willing to put in a little work. The idea of my framework, as with any framework, was to make rapid development both quick and as bug-free as possible. Java can be a real pain to work with, but these frameworks have made development much easier.

I’d also like to make a note about avoiding HashMaps in event systems. HashMaps have a definite purpose, but they can be slow, even with proper hash functions, so if you plan to have a high volume of events, you may want to avoid them. The framework I described in my post used HashMaps simply because it’s a non-issue in the environment I use it in (I recommend profiling instead of prematurely optimizing). “Fast events” were discussed by lahwran and I back when we were working on a project together, and although I (unsurprisingly) never posted my code, her work can be found on GitHub.

Added 12/16: Last paragraph

I started making mods not long after the SMP server mod “hMod” came out around September 2010. Before hMod, you had either regular hard-coded mods similar to how you have it on single player or simplistic “server wrappers” that didn’t let you do much to the game itself. hMod was different: it was the first time that you could write “plugins” for the server so that you could easily extend it, and because your plugin would mostly access hMod’s code, you wouldn’t have to update your plugin so much whenever Minecraft got updated. With this fantastic new development, I made WorldEdit, WorldGuard, CraftBook, and CommandHelper over the last quarter of the year. Unfortunately, not only was hMod on shaky legal ground, the code was a complete mess. If you wanted to adjust an event and add new features to it, you’d single-handedly break all the plugins that used that event. I felt uneasy about hMod’s future and wrote WorldEdit and WorldGuard in a way where I could easily port it to some new mod in case hMod died.

Well die it did. Only a few months later, towards the end of December 2010, a few guys secretly started up a project called Bukkit as a replacement. It was to borrow its predecessor’s best ideas while fixing its worst faults. The community for hMod was sizable, and Bukkit needed momentum in order to get adopted, especially as most server owners wouldn’t want to completely dump everything to switch to something completely brand new. With that transition, for better or worse, I helped by declaring that all future releases of my plugins would only be for Bukkit. As my plugins were pretty popular (least to say), especially CraftBook, that pretty much put the nail in the coffin for hMod and gave Bukkit life. I had good reasons to back my decision, however. The author of hMod had completely become unreachable for several weeks, and while Minecraft was still getting updated with new versions, no one left had the ability to post new versions of hMod. That wasn’t good, and it was put the future of hMod in deep question. Giving Bukkit a chance seemed like the best idea. This was around the beginning of January 2011.

I was enthusiastic about Bukkit at the time, and I got WorldEdit and WorldGuard ported pretty quickly (CraftBook wasn’t written to be ported easily, and those who are familiar with CraftBook are probably familiar with its fate). I helped Bukkit by designing the permissions system that everyone uses (with.the.nodes), as well by writing the original configuration classes and vehicle events. For the first month or so, things were rosy, but the frequency of commits to my own projects had started to fall sharply. While I was definitely busier that part of the year, the magic had faded away, and my hope that Bukkit would be the bastion of extensibility had disappeared. While there were technical issues to blame for that, there were also (and arguable still are) very strong opinions among the core team’s members about what people should be able to do and what they shouldn’t be able to do. Politics became an important fact of life suddenly. My frequency of commits to Bukkit fell even sharper. A few months later, unsurprisingly, someone started writing a mod to Bukkit itself to allow you to do things that Bukkit wouldn’t let you do. It was originally named BukkitDev, but later it changed its name to Spout. The community also changed. Everything had become cutthroat, and everyone wanted to be famous and popular (or small-time rich, as the case may be). People would write plugins to do exactly the same thing as another person’s plugins, and often times these copy-cats would even be inferior. I wouldn’t be surprised if 50% of the Bukkit plugins available right now solely exist to block fire and TNT usage.

Throughout this time, While Notch has been fairly indecisive on several occasions, he did have an opinion that Mojang shouldn’t give any preference to any particular user-made mod, and never really endorsed Bukkit, hMod, or anything else. Bukkit entered in discussions with Mojang in early 2011 in hope that Mojang would embrace Bukkit with official support, but these exchanges did not progress at all. This impartiality was a good thing, but it had its downsides. There was always some fragmentation in the community – not everything was happy with what Bukkit did, and others were definitely not a fan of the person who led Bukkit. Canary was born out of hMod as its direct successor (sometime in early 2011), with several original hMod fans as a part of the team, but it never gained traction against Bukkit. I personally never ported any of my mods to Canary after that split happened (mostly due to a matter of time constraints). However, while Canary had really little traction, it always had the chance at becoming the top server mod through hard work and ingenuity, largely due to Notch’s impartiality.

Sometime earlier this year though, Bukkit gained a corporate partner: Curse.com. They’d host the website and also fund the project, but Curse.com also was the owner of the Minecraft forums, which they had purchased previously from a bunch of Minecraft fans who started it a long time back. This obviously gave them an enormous amount of power to move the community in certain directions, and with them behind Bukkit, that meant that Bukkit had resources that no other project could dream of (recently Bukkit got front page attention on the Minecraft forums with a video that reeked favoritism for the server, surprise, that Bukkit’s project leader is an administrator on). About this time, I had started to scale back my contributions to Minecraft, as I figure I’d be in for more doom and gloom again. Those who watched me on GitHub closely may have noticed that my contributions to my own plugins and completely evaporated since summer of this year and I’ve been thankful to all the other people who have picked up the slack.

The news now is that, with Notch having moved on and jeb having taken the reins of the project, Bukkit will be responsible for the client modding API. I can’t confirm that particular fact (I’ve been pretty disconnected for the past few months), but I’ve heard that a lot of modders are not happy. Notch is no longer the lead for Minecraft, and so it would not be unreasonable for this decision to have been made. The problem that some modders have with this is that Bukkit has been exceptionally limiting (especially evident by the need for BukkitDev/Spout) and so a number of modders fear that they won’t be able to do all the great and cool mods used to be able to do. The opinions of the core Bukkit team have always been strong in allowing some mods and disallowing others. If this is so, the multiplayer and single player modding communities will finally merge in an official capacity.

When you’ve got two sides with grossly different opinions, there’s a minor chance that the community will fragment. I’ve heard wind of a few plans from various people myself, and we may have a modding community split brewing for the future. If that does happen, it’d be interesting as to whether the other side would be able to muster the clout, as Mojang will control the client and the forums will not be in impartial hands. As for me, I have to say that I have enjoyed Minecraft a lot, a lot more than any other game that I have played. Notch and the Mojang team have done a great job at making such a fantastic game, and I’ve met a lot of great and creative people throughout my time in the community. I’m not disappearing by any means, and I’ll probably be popping in still to manage my plugins, but I’m officially going to watch things settle down, hopefully this time for good, whenever that may be.

I’m not advocating for any option here. I’ve tried to keep politics away from my contributions, as most of us here, including myself, are here to have fun. However, if anyone wanted to see a server-client modding framework that has worked especially well though, you only need to look to the fabulous work in Garry’s Mod. Servers can (safely) send entirely self-contained client mods (written in Lua) to connecting players, which would work wonderfully in tandem with mods on the server. There are completely brand new gamemodes on plenty of servers. Minecraft modding, on the other hand, has been grossly inferior – full of politics and filled with the great rise and fall of many mods.

On another note, I actually worked on a server-client modding framework with lahwran and some other folk many months back (we even registered a domain name in June 2011). The idea was that servers would be able to send client mods to clients, and these mods would access a completely abstracted sandbox API. However, when that failed, it was still possible to also load separate client .class mods (not auto-downloaded, however), so you’d basically have the best of both worlds. Single player mods could also be written under the API. The main issues of the time were that Java is exceptionally un-dynamic, so giving mods the expressive power they needed was difficult. Sandboxing was a difficult matter, and we weren’t even sure if we should let mods access OpenGL, as there are already webpages that can crash your graphics drivers, simply because they have limited access to OpenGL (though no worse exploits exist, as far as I know). A lot of code and planning got done, but we abandoned it because of both time constraints and the uphill climb that we were facing to achieve adoption (it would require both server and client interaction)

• zml2008 will be managing release for the most part for CommandBook, WorldGuard, and perhaps WorldEdit.
• TomyLobo is currently a lead developer on WorldEdit and handles a lot of the cool new features. (He also has a Twitter account.)
• famerdave will be helping on/off with CommandBook.
• I will still be around, but sometimes I won’t know the answers to all your questions :)

If you are interested in helping, pop in #sk-dev on irc.esper.net and idle. You may want to get in touch with zml2008 or sk89q to get you started. Please note that you need to be somewhat experienced with Java (or rather programming in general) as I tend to be a pretty strong advocate of abstraction. On the other hand, I wrote WorldEdit when my experience with Java was pretty minimal, so you can do it too (just read up on generics and annotations).

We’re hopefully going to support these projects for as long as possible because I know a lot of people depend on it. Thanks to everyone for supporting us! If you are ever looking for a release and not finding one, you can check out build.sk89q.com for developer builds.

To make an IC, use ” =icname” (with the space in front). The ID numbers are no longer used — just type the IC name. The text goes on the first line of the wall sign.

Creating the IC

Some helpful information is shown once you’ve created the IC:

After the IC is created

Setup is like CraftBook. You have your families (SISO, 3ISO, etc.).

Setup is like CraftBook

However, unlike CraftBook, diodes are detected properly.

Unlike CraftBook, diodes work properly

Sneaking and right clicking the sign provides debugging information:

ICs can have extra debugging information shown when clicked

Access the in-game documentation with: /reic list, although you can also right click signs (while not sneaking) to see help.

In-game documentation means you don't have to remember it all

For everyone else, you can find the code on GitHub. It’s not standalone yet so you can’t use it, but NeverCast is working on fixing that.

Components

Pretty much everything is a component. Components know how to initialize themselves as well as shutdown their tasks. They are very light — most components are confined to only one class. When components are loaded, “loader helpers” help initialize the component by automatically linking resources within the class (loader helpers themselves are extensible!). For example, say I want to store sessions in this one component — I want to remember where the last person performed a command, but I only want to keep the data while the user is still logged in. There’s a component for that, and selecting it for this new component is easy with the @InjectComponent helper:

What if I need to access another plugin?

Because plugins can possibly be unloaded or be made unavailable any time (as opposed to components, which are not outside the world of Rebar), they are accessed through a proxy LazyPluginReference class. We have to specify the class of the plugin in the annotation, sadly, because generics are only known at compile time in Java.

Enabling components is a matter of placing a line in a configuration file. I run two separate servers, a survival and a creative, so often I do not use the same components on both servers.

Events

Handling events is the bread and butter of most of the features. Those familiar with the event API in Bukkit know that it’s not a particularly spectacular piece of code though. There’s a lot of code duplicated everywhere, it takes a lot of code to even initiate an event, registering an event handler is a pain, and custom events are a complete joke. I get around some of the issues by using annotations:

@BukkitEvent(type = Event.Type.BLOCK_BREAK)

Priorities are optionally specified, but it defaults to “normal.”

Custom Events

Rebar has its own improved and fast event system for custom events, and registering event handlers is even the same as the code above. (Java reflection is not at all used except during initialization.) Below is an example of a custom event to check whether a block can be modified. Because the build protection event dispatcher is only active if the build protection component is running, the requirement has to be stated (that’s noted by the @RequiresComponent annotation).

@RegisteredEvent(type = BlockProtectedEvent.class)

Creating an event is easy:

By design, a listener can contain multiple events.

Event priorities are integers, with certain default ones set at certain numbers. This allows for some leeway when setting priority.

Making Events Work

Often times multiple events need to be consolidated into one, or made more specific. For example, say you wanted to protect all signs with the text “[Lock]” on it from being destroyed. If you had to copy the same protection code to each component, you’d find it to be a nightmare! Instead in my plugin, the build protection is handled by a event that is raised by a build protection component. It allows other components to not at all worry about how to protect blocks, just which blocks to protect. It handles dependent blocks as well (e.g. wall signs on a back wall) all in one place.

I pass off a BlockProtectedEvent and whichever component feels like protecting another block can easily handle the event. The code for the actual component that fires the event is shown partially below:

Services

Services actually exist in Bukkit (I wrote it), but not many people are familiar with it, and the code is a bit generics-happy, so it tends to scare off people. However, in Rebar, I use them in order to provide a way to plug and play different parts of code and provide a little interop.

An example of a wallet service is:

The transaction methods are to ensure the possibility of atomic transactions when dealing with a player’s currency, which allows threading within the plugin as well as access from outside the server entirely.

Registering and working with services is pretty much the code I wrote in Bukkit, so I won’t go deeply into that. However, naturally, I have a loader helper for that:

Now I can support currency in any component and I don’t have to care as to what is providing the implementation!

Commands

Commands are handled by the command handling code inside of WorldEdit. It features boolean flags as well as flags of other data types (many thanks to TomyLobo), allowing you to do some pretty cool things. Annotations are also used heavily here, with an emphasis on as a little code needed as possible.

It was this instead of creating a class for each component. I purposely chose not to do that instead back then because WorldEdit had over 100 commands, which would have meant over 100 classes (something I didn’t want to deal with).

Permissions

Permissions are actually handled by WEPIF, which was improved with thanks from zml2008. WEPIF abstracts a lot of the frustrating parts of handling permissions, especially for users of Bukkit’s convoluted permissions system.

Example

Here’s an example of a component that changes your name color to a random one. I don’t designate group colors on my server — everyone gets a random name color so it’s easy to read chat and it’s not cluttered.

Source

Anyway, I actually hope to release some of this framework in the matter of a few weeks, so be on the look out! I’ve been slowly cleaning up things, and figuring out how to make some things less hardcoded (there are some limitations on Bukkit I’ll have to either fix or work around). You can watch me on GitHub if you want. If this article was mostly foreign to you, then you should read up on Java annotations and generics.