Prism-v1.5.1

Details

  • Filename
    Prism-v1.5.1.jar
  • Uploaded by
  • Uploaded
    Mar 16, 2013
  • Size
    454.73 KB
  • Downloads
    730
  • MD5
    831a5702ef311e793abdfca279dc27c9

Supported Bukkit Versions

  • 1.5.0

Changelog

Prism-v1.5.1

Requires craftbukkit 2647+

  • Updated to the new Minecart interface changes with bukkit 1700/craftbukkit 2647
  • Fixed player teleport events not tracking properly due to a missing entity assignment
  • Add a maxIdle declaration to match the max active, some users saw errors when defaults were higher
  • Adding a new config for sqlite users prism.sqlite.enable-delete-limit. sqlite doesn't allow us to delete records in batches, unless you have specifically compiled sqlite with this feature. See: http://www.sqlite.org/compile.html#enable_update_delete_limit for more info. Again, we strongly recommend mysql - sqlite is just too limited for a logging plugin.

Prism-v1.5

This plugin requires CraftBukkit Build 2645 for Minecraft 1.5 support.

While Prism 1.5 works wonderfully for 1.5, Bukkit has not yet fully added support for determining the contents and inventory click events for droppers/hobbers, and related information for the new minecarts.

I will release updates as soon as possible as bukkit 1.5 matures.

Misc New Features/Improvements

Minor Additions

  • Adding alternate player name syntax so that users can use tab-complete. /pr l a:place ollie2000 viveleroi is the same as pr l a:place p:ollie2000,viveleroi. The p: is still useful for exclusions, like p:!viveleroi, as well as:
  • Adding support for partial player name matches. Prefix any player's name with ~ - For example, using p:~vive you can match anyone with the string anywhere in their username. Just be careful - be sure you know which users match, so that you don't impact people you don't intent to.
  • Added new parameter id:# to specify a single record for l/r/r/p.
  • Items moved out of your hand are now put back when you disable the wand
  • Added dirt/grass to the list of related blocks so the rollback of one's placement won't skip the other
  • Added dirt/mycel to the list of related blocks so the rollback of one's placement won't skip the other
  • Adding support for properly tracking and restoring firework star data
  • Adding new event firework-launch, tracks launching firework rockets. Duh?
  • Adding new event fire-spread, off by default. Currently we auto-extinguish fires (if configured) on a:burn event rollbacks, but if you often have extremely large fires, the ext action may be inefficient. If you track fire-spread, it will be more efficient to run /pr rb a:spread,burn -no-ext, or if they had access to place the fire block itself instead of using a lighter, use a:place as well.
  • Tracking all block-placements of fire blocks. This will show a block-place of fire after each lighter event - and although it seems superflous, it's necessary.

Fixes

  • crop-trample on soil without any crops says "trampled empty soil" instead if "air".
  • Fixed trapdoors on the side of blocks not being tracked when a base block is broken
  • Fixed minor error that didn't properly recognize furnace and redstone lamp states as the same block.
  • Properly closing db pool connection on plugin disable.

Internal Improvements

  • Muliple performance improvements.
  • On startup, Prism will now run your purge rules in batches. You can configure the number of records deleted per batch as well the duration of the delay. This way, large purges won't consume the database/pool connections and will spread the load over time.
  • Converted to jdbc-pool from the Apache Tomcat project instead of the commons-dbcp pooling classes. They're better maintained and profiling shows they're faster with less overhead/shaded file size.
  • Added a custom metric for which database mode is used
  • Skipping block relationship checks for blocks that can't have such attachments
  • Only passing ore blocks to the orealerts class
  • Refactored our system for determining what to ignore so we do all necessary checks before processing an event instead of some before, some after.

Perm/Config Enchancements

  • Removed the prism.alerts.ignore-staff in favor of permission nodes you can now give players to ignore them: prism.alerts.ores.ignore, prism.alerts.use.place.ignore, prism.alerts.use.break.ignore, prism.alerts.use.lighter.ignore, prism.alerts.use.lavabucket.ignore or just prism.alerts.ignore
  • Added the results per page default to the config
  • Added two new configs for controller how the new purge batch system works.

Proper Vehicle Support

  • Adding support for vehicle-place and vehicle-break for powered/storage/normal minecarts, and boats.
  • Tracking vehicle-enter and vehicle-exit for minecarts and boats.
  • vehicle-break may be rolled back.
  • We properly track boat placement even if you didn't put it on water.
  • We track vehicle breaks by external entities/players hitting them, as well riders being reckless and crashing.
  • Attackers/riders may be either players or mobs.
  • Storage minecart item insert/removes now tracked
  • Tracking fueling a powered minecart

Preliminary Minecraft 1.5 Support

  • Added support for new items
  • Adding ore alert config (off by default) for nether quartz ore
  • Adding early support for new minecart types - it knows them by name only but bukkit has no API yet to get their contents, etc.

Block/Item Info DB Change

There will be a small schema change to the database (estimated wait time is 30 minutes for 22 million records). We apologize for the wait times but this schema change has dramatic benefits.

  • A significant reduction in the number of characters stored per block/item.
  • Major reduction in overhead processing during event logging, and database query result retrieval
  • Those two add up to a very noticeable performance gain

We originally designed our block data storage system with the ability to track any extra data for items/blocks/entities, but we trapped ourselves into that system for how we track every block - and 90% of blocks don't have any extra data to track. So we've overhauled how that information is tracked.

We spent a lot of time exploring other db schema changes but have seen mixed results in profiling query speeds and will not be making any larger changes.

API: (Major Feature): Custom Event Tracking/Rollback/Restore API

Track, search, rollback, and restore custom plugin events. Links to example api code at bottom

Using our API, any other bukkit plugin developer may now define custom actions and trigger events for them that Prism records - with full support for lookups, action type parameter searches, and even rolbacks/restores. That's right - Prism allows other plugins to provide code to rollback their own events!

Example: Virtual Inventory Tracking/Rollbacks

A developer of a virtual inventory plugin can easily add two new events, say vi-item-insert and vi-item-remove. His plugin can fire a custom event that tells Prism when one of those two actions occurred. Prism will record the data like any other event, and the action shortnames will even be included with a:insert searches.

The developer can also (if he wants to) define a custom "handler" - code that handles a rollback/restore event. This way, if a user does a rollback of an a:vi-item-remove b:diamondblock the custom code will actually know what to do.

Example: Custom Event Recording

DarkMythos is a plugin that randomly drops spell books from blocks, mobs, and more. The only record of players finding spells is the server log. With only a few lines of code, DarkMythos can add it's own action types to prism, and then fire an event when they happen:

Custom Event

This picture shows the dm-spell-used and dm-player-cursed events. There's not much possible for a rollback so DarkMythos just uses the events API as a way to record read-only data - like a player-chat event might.

Example Code

API: Lookup, Rollback, Restore

Perform lookups/rollbacks/restores from your own plugin.

The lookup API is ready for use. However, with all the API work we've been doing we decided to throw in support for rollbacks/restores through the API as well.

Your plugins can easily define the parameters of the l/r/r action. Prism will handle the process,
and will supply the results to you - whether it's just raw action data from a lookup or the result of a rollback/restore process.

Example Code - Lookup

Example Code - Rollback

Example Code - Restore

API: Prism Events

Prism will let you know that a drain, extinguish or rollback process has completed by triggering appropriate events. The event contains information about who run it, the parameters, and the block changes performed.

At this time, the events only contain information on block changes - mainly because plugins that will likely use the information need the block data.

Example Code

Older changelogs available at: http://discover-prism.com/blog/