[WIP] Guardian - the final replacement for BB, LogBlock and HawkEye

Guardian

~ A new age of logging and anti-grief ~

(name will probably change)

Edit by md_5: Alpha is out, get it here: http://forums.bukkit.org/threads/ad...nt-for-logblock-and-hawkeye-1-2-5-r1-0.70395/

A few days ago whilst working on HawkEye I had a realisation that really it was pointless. Why on earth are 3 separate dev teams working to achieve EXACTLY the same thing? The situation is stupid currently - one team has a new idea, the other copies it, for example. It is annoying for devs and it is annoying for server owners to have 3 plugins trying to do the same thing.

I spoke to DiddiZ (dev of LogBlock) a few days ago and we have decided to start the process of creating a completely new logging and rollback plugin from the ground up. It will take the best features of BB, LB and HawkEye with any other new ideas we come up with.

Our project is very kindly supported by MossyCobble Hosting who have provided us with a VPS to host our testing servers and websites on:

Project Team:

Lead Developers:

• DiddiZ
• oliverw92
• md_5

Web Developers:

• N3X15

GUI Developers:

• FalconGaming

What we are working off

• HawkEye - https://github.com/oliverw92/HawkEye/tree/dev (make sure you use the dev branch)
• LogBlock - https://github.com/DiddiZ/LogBlock/tree/master/src/de/diddiz/LogBlock
• BigBrother - https://github.com/N3X15/BigBrother/tree/master/src

Core features

• Scalable and efficient database schema with parent/child system
• Efficient database logging queue system (based off LogBlock)
• 'Base' command system (from HawkEye)
• Easy to use parameters for searching
• Concept of a player session
• Efficient, synchronised rollbacks (HawkEye and LogBlock)
• Threaded database query system with 'callback' classes (callbacks from HawkEye)
• Container logging without Spout (from HawkEye and BigBrother)
• Extensive API with methods for logging, searching and rollbacks for use in other plugins
• Permission manager allowing easy addition of other permission managers without having to edit any code in the main plugin (from HawkEye)
• Database cleaning and maintenance (from LogBlock)
• The concept of an abstract 'data entry' class representing an entry in the database
• Multi-use tools with the ability to bind parameters etc
• 'Questioner' that check if you really want to perform a command if it is a large radius etc (from LogBlock)
• Full support for block data (similar to BlockUtil in HawkEye)
• WorldEdit integration - 'selection' parameter for rollbacks/searching in worldedit selection
• Version checking - checks against a hosted version file to see if new versions are available. Command to download and apply the update.

Web interface (from HawkEye)

• Will be treated as a 'plugin' for Guardian
• Backend PHP will be reworked to be more of an 'API' so that it can be used for web stats etc.
• Authentication via forums (if you are logged into your forum being hosted on the same server you will be able to use the interface) - scalable so any forum can be added
• Better MySQL wrapper needed - PDO or MySQLi
• 'Presets' - customisable presets in config file that can be selected from a drop down. Ability to get the preset as an encoded 'string' that you can share with others to show them specific results etc
• (concept idea) JSON link to the minecraft server to allow authentication through permissions and a password system
• (concept idea) rollbacks from interface using JSON link

Web stats (from LogBlock)

• Will require the web interface backend to be present for use of the PHP API (to avoid duplication)
• Give control through configuration about what is displayed
• Caching of results
• 'Widgets' that can be displayed inside other pages etc

What/who do we need?

• PHP/Javascript/JQuery/JSON expert - I don't mean someone who can fiddle with PHP, I can already do that and more. We need someone who is VERY good at it and is willing to put in time to develop a scalable PHP API for the interface/stats and a JSON link to the minecraft server.
• Java GUI expert - we need someone who can help us develop a few bits of Java GUI. The main thing will be a GUI import utility to make it easy for people to transfer from BB, LB and HawkEye. Other than this there is the possibility of some sort of Spoutcraft GUI.
• Ideas - we want your ideas for features, commands, parameters etc. If you have an idea, we want to hear it

Commands

These are all prefixed by a command like /gd, /guard etc.
<derp> means required parameters
[derp] means optional parameter

• help [command] -> displays commands and information. If command is supplied, shows specific help for that command
• lookup <parameters> -> displays data matching the specified search parameters
• here [radius] [players] -> shows changes in either default or specified radius around you
• page <number> -> displays the specified page of results from the last lookup or here
• rollback <parameters> -> performs a rollback of data according to parameters
• redo [parameters] -> 'applies' the data instead of rolling it back. If no parameters are supplied it will use the ones from the last rollback (i.e. to reverse the rollback)
• preview <parameters> -> same as rollback except the changes are only shown to the person doing the command. Doesn't affect the actual world
• preview apply -> applies the preview you just did to the real world
• preview cancel -> cancels the preview
• tool -> enables/disables the lookup block
• tool bind -> bind custom parameters to the tool
• tool reset -> reset tool to default parameters
• tp [id] -> tp to the location of the database entry with specified ID

Database Schema

The problem with all 3 plugins at the moment is that the schema is not quite right. There are parts from all 3 that are good, but neither one hits the nail on the head.

The proposed idea involves a main table with a child/parent system. The main table has a boolean field 'children' and a field 'parent_id'. If 'children' is true then the plugin knows there are other entries that correspond to that entry and it can search for entries with the ID of the parent. An example:

1. Explosion goes off, this creates a singular 'explosion' action entry in the database. This entry has 'children' as true
2. Each block break has the parent_id set to that of the explosion
3. A chest was destroyed by the explosion - the contents are logged as a container transaction with the parent_id as the block-break entry which has its parent_id set to the explosion

What are the advantages of this system? Well it makes it very simple to ensure that rollbacks are complete and perfect. For example say a user tries to roll back explosions in a 30 block radius. The plugin needs to be able to see what entries are linked to that explosion or it won't be able to do a full fix of it.


As well as this parent-child system, there will also be a 'sub-table' system. Different actions need to store different data. E.e. a container transaction needs to store the item type and amount removed, a sign place needs to store the orientation, sign type and the text. The best way to achieve this is to have secondary-level tables that are linked to the main via ID. These are designed to hold the key information for the action.

You may notice the 'plugin_id' column and table. This is so Guardian can trace what plugins created what entries. For example say plugin 'DerpEdit' triggers a block break entry using our API, we want to be able to distinguish this from our internal Guardian entries.

Tables

• gd_main - primary table containing all entries
• gd_players - player table
• gd_worlds - world table
• gd_plugins - plugin table
• gd_sub_text - text entries e.g. chat
• gd_sub_items - container transactions, item drops etc
• gd_sub_block - block entries
• gd_sub_custom - custom entries from other plugins
• gd_sub_death - player death

gd_main

Code:

 id  |  date  |  player_id  |  action  |  world_id  |  x  |  y  |  z  |  plugin_id  |  children  |  parent_id  |  rbacked

gd_players

Code:

 player_id  |  player

gd_worlds

Code:

 world_id  |  world

gd_plugins

Code:

 plugin_id  |  plugin

gd_sub_text

Code:

 main_id  | text

gd_sub_items

Code:

 main_id  |  item  |  data  |  amount

gd_sub_block

Code:

 main_id  |  from  |  from_data  |  to  |  to_data

gd_sub_death

Code:

 main_id  |  cause  |  killer

Actions

This is a list of actions that Guardian will log

• Block break
• Block place
• Block form
• Block fade (leaf decay will log as this)
• Block burn
• Explosion
• Flow
• Chat
• Command
• Join
• Quit
• Teleport
• Open Container
• Container Transaction
• Player Death
• Flint Steel
• Interact (will encompass lever, button, door, pressure place etc)
• Item drop
• Item pickup
• Sign Chance
• Painting break
• Painting place
• Piston move
• Bucket
• Other

UML Diagram (rev 1)

yay

werollback ?
I'd prefer the selection/sel parameter from LB

Was thinking that. Might be better to just have it as a parameter as you say

We need to decide on parameter format. I have to say I think something like:

/lb rollback oliverw92 a:block-break b:diamond t:2d r:20

Is much simpler than your current system in logblock

My version of the schema:

lb_main


Code:
id | date | player_id | action | world_id | x | y | z | plugin_id | children | parent_id | rbacked
lb_players

Code:
player_id | player
lb_worlds

Code:
world_id | world
lb_plugins

Code:
plugin_id | plugin
lb_sub_block


Code:
main_id | from | to | data
lb_sub_text

Code:
main_id | text
lb_sub_transactions

Code:
main_id | item | amount | data
lb_sub_death

Code:
main_id | cause | killer
Signtexts, chat, commands and ips would be stored in text table.
The sign orientaion is stored as data in block column, the lines ore \0 seperatoed stored in text table.

these params are excellent. Only, if you want to rollback 2 users, then?

also i believe logblock has many more time parameters, might want to check that out too.

Multiple users: /lb rollback oliverw91,DiddiZ a:block-break t:2011.08.20-2011.08.24

Sure, that list is way too short

Code:

/lb rb player oliverw91 diddiz destroyed since 2011.08.20 before 2011.08.24

it's a bit longer, but it looks nicer somehow

You don't really need the "player" there, do you?

It doesn't really matter about length - one would hope that you don't have to roll back too often ...

...in which case the slightly longer code with clear english "time" or "before" makes sense. Again, i think this combination plugin should accommodate both, so users from bb and from lb and from HE can all use whatever params they're used to and it still works.

How about something like:

"/rollback g:VIP cd:100,32,350 t:{1d2h30s-1d3h40s} r:25 a: Chests:GoldSword/DiamondSword, Wood, Logs, Pie"

"/rollback r:25 t:<25h"

Also, how about a system logging the rollbacks so administrators can undo them should a mod go crazy?


Good initiative anyway! Glad to see an end to the whole competing-for-the-same-cake BS

Ooh, and maybe rollback requests from players? Talk to a report system for full integration including rollback requests & Confirmations Would be interesting, no?

@DiddiZ @xsolar66 My issue with that is things start getting confusing:

/lb rb oliverw92 diddiz destroyed burn steal place since 2011.08.20

and what if you only want to do cobble and stone?

/lb rb oliverw92 diddiz destroyed burn steal place since 2011.08.20 block cobble stone

How does it start working then? To me that is horrendously messy and this is much clearer:

/lb rb oliverw92 diddiz a:block-break,block-burn,chest-transaction b:cobble,stone t:2011.08.20-2011.08.22

or even

/lb rb oliverw92 diddiz action:block-break,block-burn,chest-transaction block:cobble,stone since:2011.08.20 before:2011.08.22

Those parameters are very similar to HawkEye at the moment.

If a mod goes crazy, you would just lookup his rollback commands and then do a /lb redo <parameters that he did>

Rollback requests - separate plugin really. That is more 'grief reporting'.

I know, old time hawkeye user here I used BigBrother before too, never got around to LogBlock.

Was huge DataLog fan, but I believe it couldnt roll back back then, so switched to BigBrother, cried daily over the bugs and performance, switched to DataLog when I saw "Roll back" in the description.

Ah good


I know, but the main point of the plugin is to roll back grieving no? Some form of cooperation with a grief reporting plugin to automatize it completely would be pretty next-gen if you ask me.

I've someone writing this, a LB based griefer detection, but I'm not sure if he's still actively working on.

Guess who just won himself a cake?

In my opinion there should be a separate plugin that uses the LogBlawk API to do griefer detection and management. The main LogBlawk plugin needs to be kept as a 'core'

So glad to see this happening. Now that BB is also using MySQL, will you be trying to convince them to get onbard also?

BigBrother has always used MySQL

They are welcome to join if they want to.

What's wrong with HawkEye?

I should have built it from the ground up instead of just reworking most of DataLog. There are still issues that cannot be resolved properly without very hacky methods. The database schema is not perfect. There are memory and queueing issues etc. Whilst it is a boat-load better than DataLog, it isn't quite right.

@oliverw92
when the work start? and if possible when probably come out

Don't expect it too soon. We need to plan everything carefully

sry but i like to update/use new version of all plugin xD
i hope you done in 1 week xD

and PostgreSQL support?

i've been told it's faster and better etc than mysql, and easier for me to install

I'd like to join in on this; I'm terrible at Java, but I am good at PHP and already have a good replacement for PDO in mind.

I can also hook up the repo to Jenkins once you're ready.

@oliverw92 @DiddiZ

I just want to commend you guys on this. Instead of reinventing the wheel of block logging plugins, you have teamed together to create a super plugin. I wish other developers would follow your example and team up instead of creating duplicate upon duplicate upon duplicate.

Welcome to the team

That's one main point, we need to keep in mind.