Skip to main content

Introducing Mobsistence

I’ve just released a new API for Bukkit which allows plugins to assign various metadata values to mobs to be used by other plugins (or the same plugins in later events).

Spawns and Events will be updating soon to use this API instead of local code. Spawns will store the time and location of the mob when it spawns, along with the hub/pack/etc. ids. Events (or any other plugin) can then read and modify this data to further customize the mobs.

The good news is this will separate the plugins and allow many more possibilities.

The bad news is this means all of Spawns‘ custom mobs will be lost and only the ones spawned with the new Spawns while Mobsistence is running will be saved. If this would be incredibly damaging for your server let me know and I’ll see if I can knock up something to convert the formats.

You can find its BukkitDev page here.

Events b4

The project is coming along nicely and most of the difficult things are now done.

The major improvement in this version is the addition of mob-data, which is a system of variables stored on mobs or players. What this means is you can assign your own variables to a mob when it spawns and use those in any further event. For example, you might want to give every 10th zombie a variable when it spawns and check for this variable when it dies. If you find it you can drop better loot.

You can also keep track of how many mobs a player has killed and reward/punish accordingly.


As always, the docs can be found here and the project page here.


In the last post I mentioned that I had expanded on the variables feature Mobs uses (slightly!).  In this post I’ll outline how it works in detail.  Please note that while the code for this is pretty much complete, I still might change the syntax a little before release.

First, there are three kinds of variables:

  • local – only used within the event
  • global – available from any event
  • constant – relevant to the event (and yes, I realize how odd ‘constant variable’ sounds!).

Read More

Updating a plugin

I would consider the main feature I build plugins around is potentially complex configs. In fact, the reason I wrote my first plugin was because I wanted to offer more mob drop possibilities than any current plugin did.

Finding the right balance between simple-but-limited and complex-but-overwhelming is something I struggle with daily, and spend most of my time designing and rejecting concepts for configs. Sometimes the internal code went to extraordinary lengths to keep things consistent for the users. Other times lengthy explanations and config generator apps were necessary and even then it could never be called easy.Read More