Bukkit

PluginLibSharedLibrary (plshared) is a library (optionally: plugin) which i build up while programming / fooling around with other plugins. I will detach as much as reasonable to this library, so it can be used by other developers, or even by server administrators to provide some functionality. This is used on my own server(s) and will be requirement to some plugins that i am developing or might develope, even if i might not use all features permanently, i will still maintain it.

Download jar: plshared 2.3.2

Do mind that this plugin does nothing by default and can not be configured as a plugin. However it is used by several other of my plugins, most of which are not published (yet).
Available: ContextManager, SafeWGTool (swgt)

OUTDATED INFO:

STATE:

• Unreleased, being build up to the "initial" state.
  EXPECTED BETA RELEASE: this year.
  Actually i am further going into testing this due to participating on building a server - this means that the "example plugin" will be a plugin in use on that server.
• Few stuff to move left, still there are some design decisions and changes pending as well as if/how to provide command support.
• Design decisions pending about how to bring in API / source (probably by doxygen with linked source, simply).

DESIGN:

• use as a plugin vs. use as a library: allows for easy adding as a plugin, but is not required to be used as a plugin.
• attempt to make it modular for higher level functionality, individual init methods, configurability
• classes with static methods for lots of auxiliary functionality
• global access point functionality: interfacing economies, flags, ...

FEATURES:

• economy: supporting currencies and individual accounts for name/currency - using the internal persistency layer of bukkit (EbeanServer)
• economy: ChestShop using the internal economy of plshared
• Blocks: few auxiliary stuff, like orthogonalFaces, getNeighbourBlocks for certain material.
• Inventories: auxiliary methods for manipulating inventories (lists of inventories!) and checking how much space / items of a kind etc there is.
• Items: item aliases, matching strings for item (defs like x:y or names. aliases)
• Teleport: functionality for "safe" teleport (only if space on solid ground), adjusting height to a safe spot, pollling for chunkload etc.
• Sync: some synchronization functionality like polling for something to happen, and later more.
• Warp: warp functionality with warp owners, private warps, private but shared warps, public warps.
• PlayerDelegate: A Wrapper around a player, to be able to intercept messages to the player or similar. The class delegates all method call to the player given in the constructor (for subclassing). This class however will become incompatible with each update of the bukkit API changing the Player methods.

COMPATIBILITY:

• In general i will keep it compatible with the newest Minecraft version.
• For the time being i will still try to do some tests with Minecraft 1.7.3 if i have time and if it does not get too tedious.

PROGRESS:

• now: No time to think about the big design issues, but have come to some conclusion abot how to bring in classes. Recently added a simple message browser and mail, recoded parts of teleportation, bugfixes... I might simply use this as a core library with most parts directly usable and some easy to integrate for plugin developers ( like mail or browser) - and apart from being crucial to my server core, this could well become base of some other plugins (at least in terms of copy and paste), considering extension of the message-browsing part to fit well with DarkTrace and such.
• Parts are in use on a server, that will delay the progress, but might increase the quality.

PLANNED:

• Add convenience methods for higher configurability of already existing components.
• Add convenience static methods for simple setup with/without other plugins, for centralized access.
• stuff like: setConfigPermission(boolean isPermitted)
• shared.initAll() vs init().
• enable disable flags for components (!), (lighter than disable plugins)
• example plugin activating all (based on configuration)
• persistency support: flat file helpers (see below) + threaded "now and then save" also with bean classes to be registered with a serverprovider for instance [support something like maximum number stored in memory and "maximum volumina"].
• support for different sorts of flat file persistency for easy use, as well as general persistency compatibility and auxiliary functionality.
• maybe also add op restrictions/hierarchy (conflicts with permissions though, maybe): op people but still deny them certain action. [would become obselete once the internal permission system is flexible enough to allow for this stuff with ease - TODO: check if it is the case right now...]
• permission support:
  • for internal functionality
  • compatibility: hook into other systems and also allow for adding permission definitions from other .yml files or at runtime
• some Flag support
• some language/messaging support: addressing people, depending on context (central definition how to)
• threadsafe layer, adding direct access for some fnctionality as well as interfacing: (example: run synchronous server task and wait for result, then return it, only to be called from a separate thread being allowed to block, thread-safe no-return-value calls->sync task , similar stuff)
• (add stuff from lists to this)
• (see progress)

INTERESTING:

• Intercept tp functionality (route to some safe-tp routine)
• Flat files can be dangerous! If a server provider lets the hard drive be full, some plugins opt for data loss: Support flat file persistency with a "runtime-override-file" interface / functionality for different kinds of files (.yml, some internal format, general interface?)
• (potentially ingame command based) on the fly command-delegating plugin creation (jar with plugin.yml) like "pluginlibcommands".

HISTORY:

• Initialy i wanted to write a police-plugin, monitoring fights and fighting behaviour of players, classifying what happens and then assign malus to people, then spawn police forces if players with too high a malus enter surveyed regions.
• Due to Bukkit/Mojang not providing an API for NPCs and AI in general, i decided to postpone this, even though i was planning on "tuned" wolves and zombie-pigmen as substitute forces till the API is sufficient.
• The people on my testserver wanted to build stuff, spawn stuff and ... chestshops.
• The teleporting was not 100% convenient with only using the Bukkit API.
• So i added stuff to my test-plugin...
• Dropped the police thingy until nagged to do it. Classification of PVP and "conflict-types" could still be somewhat interesting, maybe i will do that, some day...
• Actually i did implement police, but without sophisticated classification, just gather malus for attacking players on surveyed regions - and once hunted also for attacking police.