Bukkit

A generic data storage framework for cross plugin functionality. This plugin is used in the Minds of Chimera project to store data that can be easily used between plugins and on a website. The data is persistently stored in a database and accessed via a tuple of: player, world (or null), namespace and key.

Part of the Minds of Chimera Project (MOC)!

Current Use
The MOCConvo plugin (used to create interactive conversations with NPCs) will store information per player, so NPC conversations will change as they talk and the user quests.

Future Use
Unclear, but could have PlaytimeTracker and other plugins rolled into this as well as questing plugins and achievements. In this way, it would be easy to have event-based achievements, NPCs responding to quests or even reputation or time online. Paired with something like VariableTriggers, characters could have NPC quests that open doors, grant items, etc.

Installation

• Download this plugin's jar file.
• Download the MOCDBLib jar file.
• Place both jars into your server's "Plugins" directory
• Restart the server
• Shut down the server
• Configure the DBLib.properties file to configure your database (see MOCDBLib for examples).
• Restart server.

Command Line Use

Use the command line for debugging and checking values.

mocr

Says hi.

mocr set [namespace] [key] [value] {expires} {player} {world}

Sets a register entry where player and world are assumed to be self and NULL world. Expires is seconds from now, or -1 for no expiration.

mocr clear [namespace] [key] {player} {world}

Clears a register where player and world are assumed to be self and NULL world.

mocr get [namespace] [key] {player} {world}

Gets the value in registery where player and world are assumed to be self and NULL.

mocr list {namespace} {player} {world}

lists the values that are set

mocr namespaces

lists the namespaces in use by player and world

mocr run [player] [world] [namespace] [code]

executes RegisterLanguage code... i.e. a script

Programming API

class RegistryValue

public RegistryValue(int _playerid, int _worldid, String _namespace, String _key)
public PF setValue(int _val) 
public PF setValue(int _val, long _expires)
public PF clearValue()
public int getValue()
public long getExpires()
public void changeKey(String _newkey)

class MOCRegistry

public static int getWorldId(String _name)
public static int getPlayerId(String _name)

Internals

This stores values in a tuple based on the player, the world they are in (or null for all worlds), a namespace (ex. the plugin's name) and a key value. In this way, plugins can store a value in a key-value pairing, specific to a player or a player world, and not have these key-values collide because it stores them in separate namespaces. This presents developers with a lot of freedom, as well as responsibility as external plugins can enter namespaces and change values.

The databases are stored in MOCDBLib, which is a wrapper on either SQLite or MySQL, depending on how you configure it.

DB: Player and world names are pulled from the reg_worlds and wp_users tables that are created for you if you don't have them. Namespaces and keys are limited to 16 characters. As well, we create a simpler db view, reg_vals_v, that joins these tables together and makes the values more human readable if you want to debug at that level.

Expires?: This sets expires values to allow values to stop being stored after a while. So, you can set a value to be in existence for 4 hours and if you query that value at 4 hours and 1 minutes later, it will not exist. This can be useful for timed events and such. NOTE: It is supplied as either a number of seconds in the future, or as any number less than zero, signifying no expiration date.

Examples:

• ex. For the tuple (1,-1,"MOCConvo","Frank"), we are referencing a value for the player with player_id of 1, in every world and the associated key of "Frank". The "MOCConvo" namespace is used by the MOCConvo plugin for handling conversations between the player and NPCs. Basically, having longer and more involved conversation mechanisms and having the conversations respond to past conversations. So, if player_id 1 is "Notch", then we could do (1,-1,"MOCConvo","Frank") = 1, to mean that "Notch" has said hello to the NPC "Frank". Or, heck, who knows what "Frank" means, it doesn't matter, but the MOCConvo plugin will interpret the "Frank" hash to means that the player has just said hi. In this way, their next conversation would start off with, "Hello again Notch", instead of "Good to meet you Notch."
  
• ex. For the tuple (1,3,"PlaytimeTracker","moved"), the "PlaytimeTracker" is another of our plugins that logs data. If we associate "moved" with distance moved, then we could log all of the player's movement for a world in that value.
• ex. For the tuple (MOCRegistyr.getPlayerID("Notch"),MOCRegistry.getWorldID("MainWorld"),"MOCQuest","Gather Wood"), we could store their progress on a quest "Gather Wood" and each time they pick up wood, it increments this value. Then, when they go back to a questgiver, it checks this value.

Development Status

• 1/22/2013 - be nice to have "get" use * to return multiple i.e. get "items.metals.*".
• 2012/10/16 - Jar exists and is in development. Will release when MOCConv is released (i.e. bugs worked out and the API for this is more solid).
• UNDER DEVELOPMENT: Working on interpreted language to allow plugins to specify tests on these bits so players can author them with logic.
  I.e. Is the value of the key > 5? : GT(5,$curr)
  I.e. Is the value set? : ISSET
  I.e. Is the value at "A" less than the current value : GT($A,$curr)
  I.e. Increment the value : INC($cur) or INC or
  I.e. Add 5 to the current value: +5
  
• IDEA: Allow plugins to specify responses to changes in values... i.e. a listener/response framework.