HawkEye Reloaded
NOTE
HawkEye Reloaded is still under active development! Due to many table altering changes we've been making, we've only been uploading new releases to our Jenkins Development build website.
Bukkit 1.7.10 / Spigot 1.8 Users
The current builds on bukkitdev are mostly outdated for builds 1.7.10 and above. I highly recommend you download a development build to avoid issue!
Description
HawkEye reloaded is a continuation of the beloved former "Hawkeye", which is now completely inactive. It gives you the ability to log changes, search through them, roll edits back and much, much more.
Features
- Logging of over 45 different actions
- Worldedit logging
- Smart logging
- Smart rollback/block restoral
- Block filter to avoid logging unwanted material
- Rollback commands with simple-to-use parameters
- Advanced interactive web interface for viewing logs
- Rollback previews - have the rollback only appear to you at first
- WorldEdit selection rollbacks - rollback everything in your WE selection
- Configurable search tool to quickly see edits on single blocks
- Simple, and easy to learn parameters
- Fast efficient logging
- API so other plugins can interact with the HawkEye database
Command List
Command | Description |
---|---|
/he help <Command> | Provides help for the specified command |
/he | Displays a page showing all HawkEye related commands |
/he tool bind | Binds the custom parameters to the tool |
/he tool reset | Resets tool to default properties |
/he tool | Toggles the searching tool |
/he search <parameters> | Searches the HawkEye database |
/he page <page> | Displays a page from your last search |
/he tpto <id> | Teleport to the location of the data entry |
/he here <radius> <player> | Searches around you |
/he preview apply | Apply the rollback preview |
/he preview cancel | Cancel the rollback preview |
/he preview <parameters> | Preview the rollback changes |
/he rollback <parameters> | Rollback specified changes |
/he undo | Reverses your previous rollback |
/he rebuild | Re-apply specified changes |
/he delete | Deletes specified data entries |
/he info | Display important information |
/he writelog <parameters> | Write results to a log |
Permission List
Node | Description |
---|---|
hawkeye.* | Access to all HawkEye commands |
hawkeye.page | Permission to view different pages |
hawkeye.search | Permission to search the HawkEye database |
hawkeye.search.<action> | Specific node to search HawkEye database |
hawkeye.tpto | Permission to teleport to the location of a search result |
hawkeye.rollback | Permission to rollback actions |
hawkeye.tool | Permission to use the HawkEye tool |
hawkeye.tool.bind | Permission to bind parameters to the tool |
hawkeye.preview | Permission to preview a rollback before applying it |
hawkeye.rebuild | Permission to rebuild actions |
hawkeye.info | Permission to view info |
hawkeye.writelog | Permission to writelog |
Requirements
- Latest RB of bukkit
- MySQL database (Your host should provide you with one)
- (optional) WebServer (if you want to run the Web Interface)
Development builds of this project can be acquired at the provided continuous integration server. These builds have not been approved by the BukkitDev staff. Use them at your own risk.
Still have a question?
Still have a question?
Here is an extra help page, which contains things like, format, importation, and errors. If nothing helps, feel free to open a Ticket, explaining your problem will help us recreate, and fix the issue.
Want to Donate?
Want to Donate?
All the donations go directly to the former author oliverw92
I am currently very busy and cannot answer any questions.. I will try to keep all my plugins updated during my absence
@bob7l
Fix it!
@Puremin0rez
That's very weird.. Can you guys just downgrade a little?
@Puremin0rez
Same here!
@Puremin0rez
Same here.
PureminOrez everything still works for me as it worked before you should try to reinstal the plugin if you didnt already did this.
yet this plugins needs to get the update with the UUID's other wise it will never be trusted by mc bans
hope they read this as i think they dont.
I think this commit has broken right clicking with the hawk tool, whenever i right click it just places the block rather than returning hawk results. Left click still works.
https://github.com/Bukkit/CraftBukkit/commit/6efeddfe5779931ac3b272010022a41a1c39f1d6
@bob7l
For example mcbans will want (when name changes happen) proof of uuid of the logs. Names will not be reliable and will never be trusted after that point.
@Vivi_Coral
Probably means the plugin is unable to save a entry to the MySQL due to it being null, or containing a null value.
Hey dev, good work, the plugin works very good on my server, but could you add option to prevent log ONLY blocks break in some world guard region because i have a prison server and i doesn't want to log blocs break in mines. Is it possible to check if you can add this and update the plugin 1.7.2 and up please ;) I use 1.7.2 bukkit version on my server.
Is it possible to add option to log all into flatfile directly on the FTP? And per player files if possible? That should be amazing if you this 2 things ;)Â :)
Continue your very nice job
Hi devs.
I'm not sure why, but I'm getting lots of the following in my server console log:
" WARN]: [HawkEye] null "
Can you advise?
which permission node contains the permission to /he delete command? or is there a permission i can negate to remove the /he delete command from certain staff members?
uuids need only be considered during player logins - is this a new name/uuid combo, or is it an existing one. And considered for saying "Do you want me to search all of the same player results, or just this particular one" .. uuid to guide to the player_id entries to pull out of the database - player_id =x OR (player_id=x or player_id=y)
For offline servers, how does anything change? If anyone could log in with the name Notch, how was Notch as a search term a guarantee of uniqueness to an individual? If one can join as Notch, 10 can join as Notch. Unless there was password secondary software, and the first Notch joining got to set a password to block out the other 9. And so you get rid of Notch, and he rejoins as jeb, leaves, logs in as dinnerbone ... same guy three different names, no way of knowing they are the same guy before. How were you handling this before on cracked servers? You weren't.
The uuids dont need to be loaded-up for the majority of the searching. Only if a search for a player name is ambiguous, then a need to use it to show it refers to different player accounts.
Once the player logs into the server, the name is the name. The uuid will be part of the player object already, you dont need to then load up a separate list of your own. Lookup the player_id for an edit from the two intrinsic features of the account. Nothing changes in the master hawkeye data table, it is still a record crosslinked by player_id which is a unique number you assign to each unqiue logging person on the server - before it was playername, now, playername+uuid. Lookups for a 'playername' will more often than not hit a unique entry - most servers will have a percentage of players change names, but, not the majority of them, repeatedly, and not a tremendous amount of 'i will change my name to the one that that guy vacated in order to have some fun with people here' events either. On the chance that they don't, a name-only query of the playerid table would return multiple uuid pairs, and then the searches require this ..clarifcation
But searching for "all the edits done by whatever name the account belonging to the guy known as bob7l" would distill into changing the search query from (player_id=4) to (player_id=4 or player_id=434) when pulling up the records.
Yes, a uuid is long, but, stored properly as a number, blazingly efficient compared to string storage and lookups from a database. Your hawk_player table will be much bigger each time a new user is added to it, but not massive. The existing main table will be.... the exact same as it is now, growing by hundreds and thousands of rows per minute on many servers... New player joins, new record with name\uuid made, then he goes off building and breaking for 10 hours. Total cost: An extra 32 bytes to the ENTIRE database to record that player for 10 hours than it currently costs.
Player changes name, comes in, new entry same uuid, new name - more than just 32 bytes more this time, as its his name too of course, now the same player account is consuming like 120 bytes in the database table. For two different names. Twice as many player_id entries as he would have generated currently, the bastard! Yet only one is active currently, and the data logging still goes on the same as before just with a new way to get this player_id to record.
If you're saying "wooo, we have to load the uuids into memory for each player in our table when the server starts' then you're doing something wrong... why should you load a list of thousands of entries in to memory for a handful of players to be checked against? " No, if you're saying "woo, we have to load the uuids of all the online players into memory in order to work against our tables" ... already done, its part of the player object, whether your plugin is on the server or not.
the uuid need not be exposed to any human at any time, merely used to generate the player_id for logging, or to help resolve ambiguous name searches , or to help group 'same account, different name' results together.
Logging an extra 32 bytes per player row in the player id table seems rather trivial given the hundreds and thousands of rows worth of edit data generated per hour. Adding another row to the table when they change their name simply adds another single row.
And offline server considerations are really... no different than before. If Alex at home sits down and logs in a Notch, that account name will have a unique uuid (mashed together from a constant string + namestring). So you have a uuid. The only difference with offline servers is that before, Alex could login to an offline server as Notch, then logout and login as jeb, then logout and login as dinnerbone and now with namechanges ... Alex can sit at home and login as Notch, then logout and login as jeb, then logout and login as dinnerbone. Zero difference.
Before, Brian could then also login as Notch, and claim ownership over all the loot that Alex collected as Notch... and all the breaks that Alex logged in hawkeye as Notch would be jumbled up with all the breaks that Brian is doing with the Notch account. player_id table has only one entry: Notch Yet two players have helmed that account name, how did the offline servers ever deal with such chaos before? With the new system, Alex comes in as Notch and a unique uuid is generated, you record the uuid+Notch in database. He logs out, and Brian then comes along and logs in as Notch. The uuid will be.... THE SAME as it was for Alex's Notch. End result: one player_id entry, for Notch + uuid. Two players at the helm. Im sure that whatever systems offline servers have used to prevent multiple users using the same account name will still exist, because thats all they have to do - make sure that when Brian logs in as Notch, he hits the barrier left by the first guy using the Notch account, Alex, and is unable to do anything but logout.
UUIDs mean absolutely nothing to an offline server, they do not change a SINGLE THING with how the server operates, except they will indeed exist to be a placeholder for the meaningful use of UUIDs in online servers. They will be there so that economy plugins which Exclusively will store balances against UUIDs only will be able to work. The main difference for an offline server is that the uuid will be 1:1 constant locked to an account name regardless of who uses it, which makes it no more significant than the name, which makes doing lookups on Notch+uuid no different than doing lookups on Notch right now
it tells you nothing of who actually was at the helm of the account, nor does it tell you what other names the operator has logged in under.Online servers, name changes for hawkeye
> extra rows for player_id in order to preserve the name at the time, the ability to see namechange histories, etc. Or else just use the uuid in the player_id table, and then deal with getting the display name to use.. but when you want to do search by names, that would then put a lot of work onto having to go over all the user accounts to find names that match, and dealing with all that from bukkits end, compared to you already having the names in the database to look up with your own control over it.@TheBoomer
But you also have to consider the other things.. Like one: Cracked servers. Or two, what will we do with the current player database? Or even three: The UUID's are very long.. All that's gonna do is eat up A LOT more ram when we load all the players to memory. Not to mention we'll now be FORCED to query through the entire list and UUID check each entry every single time.
Modify user table:
player_id, uuid, name, and enumerator (1, 2, 3 ..) to denote which name was used at the time of edit, such that the name+uuid give the cross-ref ID number for storing in the main table. 1, 2, 3.. record the order of name changes for that UUID, the nth out of n is the current known alias. User logs in with same uuid, different name, stuff that into the db right away. No changes to the main table logging system, you are still recording an entry crossed-up with a table of distinct username/uuid records instead of just username records)
Presume then that over time the folowing EXTREME sets of name changes occur: We have Alex join, change his name to Brian, then later chane his name to Charlie. After he freed up his Alex name, Dan changes his name to Alex, then later, changes it to Evan. And, now a new player joins for the first time, the name Alex being available for him and him ironically hitting this server...
Pretend then we have the following table entries for the Hawk_players: The UUID+name defines the player/name that performed the edits at a given time. The player_ids where the UUID is the same are the same account. The 1/2/3 is maybe not even necessary, as the order of IDs can be used for ordering history
Now from that:
Search results can be set/flag operated to output ALL edits using a current-name display, or with name-at-time displayed.
Names displayed should have a symbol/coloring to indicate it is the current/only uuid-name stored, or if it is an older name that has been changed, ie, outputting a block history that Alex/Brian/Charlie broke would output
Brian(Old) or Charlie(Cur) depending which name broke it at the time.
If I want to search for something for p:Alex, it is unclear which one, so instead, output a table of the accounts with Alex in the history. Spit out the player_id number beside each name, outputting for example. The player_id number is unique, specific, identifier you already have : Now i can modify a search to use the combination of p:Alex i:853 to specify either the player_id to lookup, or the account (all player_ids for that uuid) to lookup. The ID would be all really needed, but, specifing both would be an internal check to prevent accidentally typing 852 for which there is no Alex entry...
Use flags or parameters to search/rollback what I can impact/see, such that the query acts on just the selected player_id or uses the set of player_ids based on the UUID I say belongs to Alex-853
And again, the display flag/options such that whatever results I get to display, I can have them all displayed as "Evan (Cur)" or as "Dan (Old)", "Alex (old)", or "Evan (Cur)" depending on which name did the recording.
I can use p:Alex i:853 with one flag to specify just player_id 853 in query, or another flag to specify the entire UUID, which will construct an SQL query where {player_id=201 or player_id=853 or player_id=1377} and {all other query expressions}
The long UUID is never needed to be exposed at all in the results, it is only used to identify the set of player_id numbers that belong to the same minecraft accounts, and you display either the name-at-time or name-currently as a selectable output by always recording new information, and never modifying/destroying the player records.
---------
Data migration for existing servers would involve adding a new column(s) to the hawkey_player table, and performing the bulk existing name to UUID conversion. All existing data remains untouched, player_id 144 is still the same entry it was today, just now with the uuid that is in place. In the future, when this guy changes his name, a new player_id gets made for the same uuid but different name combo.
@Liger_XT5 Ahhh i see your point.. Only issue is.. How exactly will i display this info..? UUID? It would look weird..
@bob7l
Add UUID to the log
@bob7l
It would be greatly appreciated that we could tell if someone griefed, then changed their name, that way we could see it was the same person. Same goes for when someone is banned, they change their name, and ask why they are banned and want proof, then all the admin has is logs of a different name.
@baemboo
Does it break? I don't think the UUID system effects us much.
UUID Update needed!
Can hawkeye log item-frames? It logs the frames themselves for me but not the item inside of it.