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

Discussion in 'WIP and Development Status' started by oliverw92, Aug 27, 2011.

Thread Status:
Not open for further replies.
  1. Offline


    ~ 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
    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


    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.

    • 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
     id  |  date  |  player_id  |  action  |  world_id  |  x  |  y  |  z  |  plugin_id  |  children  |  parent_id  |  rbacked
     player_id  |  player
     world_id  |  world
     plugin_id  |  plugin

     main_id  | text
     main_id  |  item  |  data  |  amount
     main_id  |  from  |  from_data  |  to  |  to_data
     main_id  |  cause  |  killer

    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)


    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 19, 2016
    Cirno, afistofirony, Orcem12 and 54 others like this.
  2. Offline


    yay :D

    werollback ?
    I'd prefer the selection/sel parameter from LB
    afistofirony likes this.
  3. Offline


    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
    Raldo94 and xsolar66 like this.
  4. Offline


    My version of the schema:


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

    player_id | player

    world_id | world

    plugin_id | plugin

    main_id | from | to | data

    main_id | text

    main_id | item | amount | data

    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.
    sin_samsonsin and Mr_H4mm3r like this.
  5. Offline


    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.
  6. Offline


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


    Sure, that list is way too short :D
    /lb rb player oliverw91 diddiz destroyed since 2011.08.20 before 2011.08.24
    it's a bit longer, but it looks nicer somehow :D
    Neateshot, EarlyLegend and Mitsugaru like this.
  8. Offline


    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.
    swampshark19 likes this.
  9. Offline


    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?
    efstajas likes this.
  10. Offline


    @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'.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 19, 2016
  11. Offline


    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.
  12. Offline


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


    Guess who just won himself a cake? :)
  14. Offline


    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'
  15. So glad to see this happening. Now that BB is also using MySQL, will you be trying to convince them to get onbard also?
  16. Offline


    BigBrother has always used MySQL

    They are welcome to join if they want to.
  17. Offline


    What's wrong with HawkEye?
  18. Offline


    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.
  19. Offline


    when the work start? and if possible when probably come out
  20. Offline


    Don't expect it too soon. We need to plan everything carefully :D
  21. Offline


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


    and PostgreSQL support?

    i've been told it's faster and better etc than mysql, and easier for me to install :p
  23. Offline


    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.
  24. Offline


    @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.
  25. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı

    One of my biggest issues with any plugin I've used so far for making major changes, is that they all seem great at handling small (sub-1000 block) changes but suck at scaling up into tens of thousands. Make sure that this system can handle somebody rolling back half the map and then redo it properly without crashing and losing all the data.
    [qwerty] and rakiru like this.
  26. Offline


    Welcome to the team :)
    That's one main point, we need to keep in mind.

    btw, i just finished dynamic tools:

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 19, 2016
  27. Offline


    Great guys I hope you got this fast, want to use it asap :D
  28. Offline


    Haha 1 week is wayyy too soon. Talking a month possibly. Hopefully less, but I can't start proper development until the 2nd or 3rd - I have a very important exam on the 2nd. Before then we can hash out all the details, maybe get some schema tests going.

    In all honesty, the headache that supporting PgSQL would create outweighs any kind of performance benefit. PgSQL has benefits on large scale databases - much larger than we are talking about.

    Awesome! Could really do with someone dedicated to the interface and stats page. Have you got much Javascript, JQuery and JSON experience?


    Did you ever try HawkEye for that? I exploded 3000 tnt causing 60,000 block breaks. It rolled it back in under 2 seconds with the server being 100% responsive throughout. The redo took even less

    Not quite sure what that means?

    Name still isn't perfect in my opinion. Was talking to my mate earlier, thoughts on 'WatchMen' or 'WatchMan'?

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 19, 2016
  29. Offline


    To be honest, my favorite name out of all of them was HawkEye.


    I'm really looking forward to this. I don't care if it means the death of BigBrother, LogBlock, AND HawkEye. If it leads to a much more stable teamed from the best of the developers from those plugins I'm -ALL- for it!
  30. Offline


    Now, LB has a config for dynamic tools. For example:

            item: 270
            leftClickBehavior: NONE
            params: area 0 all sum none limit 15 desc silent
            rightClickBehavior: TOOL
            - t
            defaultEnabled: true
            mode: LOOKUP
            item: 7
            leftClickBehavior: TOOL
            params: area 0 all sum none limit 15 desc silent
            rightClickBehavior: BLOCK
            - tb
            defaultEnabled: true
            mode: LOOKUP
            item: 18
            leftClickBehavior: TOOL
            params: all area 0 silent
            rightClickBehavior: BLOCK
            - rbt
            defaultEnabled: false
            mode: ROLLBACK
    So "/lb t" and "/lb tool" will work to get the first tool, and the permissions are always: logblock.tools.<tool name>
    Year, it pronounce like LogBlarg :D

    BlockGuard? LogGuard? Guardian?
    Something with guardian sounds good :D
    Year, when we'd keep the origial plugins alive, this one would really miss it's intention :D
Thread Status:
Not open for further replies.

Share This Page