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.

A shop with in stock and out of stock chests

But there was no currency. I deliberately avoided establishing currency because a number of friends were adamant about not having one, but their disdain for currency isn’t unreasonable. I’ve been around and how “economy” works on many Minecraft servers (as well as other in other games) is through a combination of periodical welfare payments, game-powered shops with rates set by the game, and in the case of roleplay servers, virtual employment. In the case of the shops, rates for multiple items were set by the server owner manually or through a list of item rarities (generated by finding the distribution of materials in a given world). I find the latter particularly farcical – value is very much not simply determined by rarity. On more than a few servers, it seemed as if everyone’s business was to farm sugar cane en-masse – and it worked, because sugar cane as bought by the server’s shops at a fixed price. I didn’t want that and I got the feeling that my server’s players didn’t want it either.

There was, of course, another choice – have algorithms dictate the exchange rate based on the volume of trades by players. A player had suggested this as well, but that meant that I’d have to dedicate time to researching and tweaking the algorithm (although the player said he had some experience with this), plus it’d be open to market manipulation due to the small volume of trades that happens when you only have a smaller server. If I made an error, it could significantly tip the balance the wrong way and I’d have to deal with the aftermath (and after taking a one or two week leave, as it tends to happen). Instead of all of this, I was anticipating that a currency might develop on its own (commodity money). Two different groups of people did setup currency exchanges, but their exchange ratios were not properly fair. One diamond-for-gold exchange ran out of diamond in an hour because the diamond was too cheap for the amount of gold. Beyond that, there wasn’t enough trust to be had for the exchanges and they didn’t catch on.

While bartering has been enjoyable, trading can be challenging because you may not have the item the seller seeks, and you’re also encouraged to delay trade until the real necessity arises. With bartering, some items are impossible to sell because the effort involved in trading for them (and calculating the right barter ratio) is significantly greater than crafting the item themselves, even if prices are as low as you can go. That leaves us with need for an official currency, and probably one that’s driven by money a la a credit card (to lubricate the process even further). We spent a bit of time discussing what to do about that, and I had considered giving everyone a set amount of credits (perhaps 10,000 per head) – something that I can do because it’s a computer game – but I think the currency would never come into use nor stabilize. What we probably will do is setup a certain number of one resource for a certain amount of money at a game-controlled exchange. It’d be a fixed currency backed by gold or something, mostly likely to be something like iron ingots or gold ingots. It seems no one wants fractions either (although decimals is merely a representation), so we’re thinking about having the exchange rate at a large whole number such as $32 for an iron ingot. It has to be high enough to make it possible to trade lower-value items – a great analogy for that, as a friend said, is if the lowest currency denomination suddenly had to be $20 USD, you could no longer trade a large number of objects unless it was in excessive bulk quantities. Another friend suggested using factors of $8, because most items have a stack size that’s 64 or a multiple of 8 – that’s an interesting idea. The question also arises whether we’d want a floating exchange rate in the future too.

One of the currency exchanges

Someone abusing the in-game 'tablet' image board app to advertise

Overall it’s been pretty fun trying to stimulate trade and there has been many analogies to history and real life. Because new versions of Minecraft also continue to come out, the value of items can change. Gold’s value may change in v1.9 because of new items added, and one could currently move money into or out of gold ingots in anticipation, depending on how they expect the value of gold to trend. There’s also been some clever people really working the market (perhaps quite in an evil manner), by, for example, buying out a shop and reselling  with higher markup. Some of the guys on there are younger too, and some of them have really sharpened lately.

• Name spoof fix for 1.8.1 (ZIP)
• Name spoof fix installer for 1.8.1 (Windows installer)

A server-side fix has recently made it into a Bukkit, but your account can still be abused to join unpatched servers. This client-side patch prevents any server from exploiting your account. To understand how the exploit works, here’s a review of how Minecraft would authenticate for “Frank”:

1. Client->Server: Your game tells the server that it wants to join as “Frank”
2. Server->Client: The server responds with the ID “afe93b31c” (randomized)
3. Your game tells Minecraft.net that “Frank” is joining “afe93b31c”
4. Client->Server: The client tells the server that it’s ready
5. The server asks Minecraft.net to see if “Frank” has joined “afe93b31c” (if not, then the real Frank never joined the server)

Here’s how the exploit works: You get your victim to join your custom server that sends a blank ID. Frank’s game tells Minecraft.net that Frank is joining “” (a blank ID). Frank joins your server, plays around, and has no clue about what’s going on. You then join Frank’s server where Frank is an administrator, but you immediately skip to step #4: You tell the server that you already did step #3 and you get in. Why does this work? On the server, the server ID is blank if you never complete step 1, so in step #5, Frank’s server asks Minecraft.net if “Frank” has joined “”, which Frank did earlier but on your server.

From a more technical perspective, the hacked client never sends the initial handshake packet. The server ID starts out as a blank string, and it’s only initialized if you send the handshake packet. If you skip the handshake packet and just jump to the login packet, then the server ID stays as a blank string. Before 1.8, your client would freely accept a blank server ID. 1.8 prevents a server from giving you a blank server ID, but Lymia noticed that the game doesn’t URL-escape the server ID, so a server ID of “&” is essentially blank. The patch makes the routine URL-escapes the ID.

Addendum: Someone mentioned a “man-in-the-middle” attack that allows for name spoofing, but that’s a different issue that can only be fixed with significant changes to how Minecraft handles authentication. (A MITM is also more difficult to pull off well.)

If you are curious as to how it’s done, you can check the Git repository for the commit. I caution you that the code is pretty dirty — my proof of concept code tends to be that way. I dabbled in the fix a few months back, and I forgot its proof-of-concept status when I dropped it into PlayX the other day.

Another cool change is the addition of the “PlayX Navigator.” It allows you to browse video sites (presently only YouTube and /r/videos) to play them in PlayX. If you click on a YouTube URL, it will be redirected to PlayX instead, allowing you to use YouTube.com’s search page like normal. The browser can also visit any URL, and you can force a link to open a video in PlayX by using either of the following URIs:

• playx://open/<uri>
• playx://open-provider/<provider>/<id>

Find PlayX 2.6 in the usual repositories.

However, I suggested that he queue a function as if it was an animation itself, and use that to fire off the animations each run. That is illustrated below.

The snippet is simple —

1. The list of animations is fired. These will be queued to be executed.
2. Then the anonymous function itself (arguments.callee refers to the function being executed) is re-queued.
3. next() progresses the queue. next is passed in as an argument.

The nice things about Spotify are:

• Songs load very quickly. Overall, just click a song or anything and it will be playing right away — no wait.
• The program is fast and looks good. This seems to be a rarity these days.
• The music selection is decent. I haven’t found some more obscure artists, but I’m satisfied.
• The social elements are decent. As I mentioned, you can make playlists, including collaborative ones. A great feature is that you can send a song to a friend — just drag the song to the friend and it’ll show in his or her Spotify “inbox.”

Does it compare to Pandora? No, not really. Pandora doesn’t let you play songs on demand, but it does have a great music discovery service — one where you can just sit back and mind your own thing as it chooses songs for you. Spotify has “similar artists,” but that’s about the end of its music discovery service. There are some user-made tools for music discovery with Spotify, but they use Last.fm’s database, which is based on user contribution and not so much computer algorithms, so it’s not as “accurate” as Pandora. (On a related note, there’s a new Pandora interface, finally.) Edit: There’s a radio service outside the US for Spotify.

Grooveshark? Grooveshark’s qusai-legal database uses uploads from users, so songs are unorganized and the selection is very spotty. Grooveshark also loads songs fairly slowly. The main advantage of Grooveshark is that is more “free,” but otherwise Spotify blows Grooveshark out of the water.

What don’t I like?

• Everything is excessively tied with Facebook . It doesn’t seem as if you can even use the social elements unless you’ve linked your account to Facebook.
• The social features could use some work. To add someone to my friends list (not through Facebook), I had to enter spotify:user:<username> in the search, which was awkward. (If there’s a better way, do tell.)
• Collaborative playlists can’t be shared publicly, probably because there’s no way to change individual editor rights for friends and whatnot. For the social features that are available, they are pretty barebones.
• You can’t actually buy songs to “own.” Edit: You can do this outside the US.

Hoping to get into Spotify? Right now they’re invite only. If you have an internet presence, you can try getting an invitation through Klout.com (whenever it’s not closed off). No go? You can try registering an account from a UK internet address (note: this gets you a more restricted European account). If you can’t get in and don’t want to wait, you can purchase an unlimited account for $5 or go premium for $10 and get in instantly. If you don’t purchase a subscription, be aware that the “Free” version you get will eventually become as restricted as the “Open” version in Europe.

There’s only an official Android app, but I haven’t used it so I can’t comment on it. My friend has a (semi-old) review on Spotify for Android though.