UploadedMar 17, 2013
Supported Bukkit Versions
Please note: Prism 1.5 requires CraftBukkit 2647+.
- Fixing a database query issue that caused trouble with block parameters
- Fixed a related query issue that caused sql errors, and eventually pool exhaustion errors with inspection wand
/prnot showing the default page.
- Fixed sign events erroring out when another plugin rejected the sign text change.
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.
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
- Adding alternate player name syntax so that users can use tab-complete.
/pr l a:place ollie2000 viveleroiis 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:~viveyou 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:burnevent 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
- 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.
crop-trampleon 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.
- 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.
- Removed the
prism.alerts.ignore-staffin favor of permission nodes you can now give players to ignore them:
- 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-breakfor powered/storage/normal minecarts, and boats.
vehicle-exitfor minecarts and boats.
vehicle-breakmay 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-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
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:
This picture shows the
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.
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.
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.
Older changelogs available at: http://discover-prism.com/blog/