LogOres
What is LogOres?
I wrote this as an anti-cheat plugin, along the lines of NoCheat, FoundDiamonds and AntiXRay. It's purpose is to log ores that people are mining so that you can look for cheat patterns. It also does some calculations that make it easier to look for these patterns rather than just manually correlating FoundDiamonds, LogBlock, etc (which is what I used to do).
How do I install it?
- Download the latest version here
- Copy the jar file into your plugins directory
- Restart your minecraft server (or if using PlugMan, you can live-load by typing "/plugman load LogOres")
- (Optional) Tweak the plugins/LogOres/config.yml and then type '/lo reload' (permission 'logores.admin')
Source code available here
How does it work?
LogOres does some basic checks/calculations on ore activity to help you find cheaters without having to do all the manual correlation yourself. You specify the ores you want to log in a config file:
# default 14 (gold), 15 (iron) and 56 (diamond) - MUST USE DATA VALUES # [URL]http://www.minecraftwiki.net/wiki/Data_values[/URL] loggedOres: - 14 - 15 - 56
and then it will log any mining of those ores to a file, like so:
[Sat Jul 09 09:30:59 PDT 2011] IRON_ORE broken by morganm at (x= -91, y= 11, z= -47, world=world) [Sat Jul 09 09:30:59 PDT 2011] IRON_ORE broken by morganm at (x= -92, y= 11, z= -48, world=world) [Sat Jul 09 09:30:59 PDT 2011] IRON_ORE broken by morganm at (x= -91, y= 10, z= -47, world=world) [Sat Jul 09 09:31:59 PDT 2011] IRON_ORE broken by morganm at (x= -90, y= 9, z= -48, world=world) [Sat Jul 09 09:31:59 PDT 2011] IRON_ORE broken by morganm at (x= -90, y= 9, z= -49, world=world) [Sat Jul 09 09:33:49 PDT 2011] IRON_ORE broken by morganm at (x= -67, y= 38, z= -63, world=world) [t= 109sec / (d= 40 / b= 101) = r=278.2] [Sat Jul 09 09:34:39 PDT 2011] IRON_ORE broken by morganm at (x= -49, y= 31, z= -61, world=world) [t= 54sec / (d= 19 / b= 59) = r=164.1] [flagged]
Note the extra details that were added to some entries, I'll explain those further in just a moment.
LogOres keeps track of the most recent ore a person mined and compares that to the current ore. If the ores are > minDistance (default 5) blocks apart (in order to ignore clusters of ore), it will print out the time since last ore (t=), distance (d=), number of non-ore blocks (b=) and the ratio between them (r=) all. The ratio calculation is: time / (distance / blocks). This has the effect that smaller ratio numbers indicate a higher likelihood of cheating, as explained in more detail below.
Examples
Here are some examples of the extra information that is logged:
# 60 seconds between ores, distance=60, 120 blocks broken # this is mining straight between ores (2 blocks * 60 distance = 120 blocks, ie. just enough room to walk) [t= 60sec / (d= 60 / b= 120) = r=120.0] # 180 seconds between ores, distance=60, 250 blocks broken # this is same distance, but taking longer and breaking more blocks to get there - more "normal" mining [t= 180sec / (d= 60 / b= 250) = r=750.0] # 180 seconds between ores, distance=20, 250 blocks broken # this is an example of a normal horizontal zig-zag mine, where the ore is closer but took just as long as previous example [t= 180sec / (d= 20 / b= 250) = r=2250.0]
So we can see that the closer the ores are together and the longer time/blocks it takes us to get there, the less likely we are cheating and the higher the ratio. The further the ores are apart and the less time/blocks it takes us to get there, the lower the ratio and the more likely that we are cheating to do it.
Be sure to verify in-game that cheating actually took place!
Please note that someone having a low ratio does not immediately mean they are a cheater. It's possible for ores to just be in a straight line, or for someone to just be in a lucky ore-rich area. On the other hand, a consistent pattern of low ratio ore mining, especially between ores that are very unlikely to be in straight lines (like diamonds) indicates a high cheat probability. I always personally tp to the locations and look for the tell-tale "cheat tunnels" just to verify - this plugin just makes it much easier to focus my attention on likely cheaters rather than manually sifting through lots of logs to find them.
To additionally help make it easy to focus on high-probability cheating, there is a "flagRatio" config option, for which any ratio below this value will append a '[flagged]' to the end of the log entry. By default this is set to 250, which I've found to be reasonable but you can certainly play around with it to find the value that works for you. Thus it becomes a very easy matter to look for possible cheating:
> grep flagged oreLog.txt [Sat Jul 09 09:34:39 PDT 2011] IRON_ORE broken by morganm at (x= -49, y= 31, z= -61, world=world) [t= 54sec / (d= 19 / b= 59) = r=164.1] [flagged] [Sat Jul 09 09:35:09 PDT 2011] IRON_ORE broken by morganm at (x= -51, y= 30, z= -72, world=world) [t= 17sec / (d= 12 / b= 19) = r=26.6] [flagged] [Sat Jul 09 09:35:39 PDT 2011] GOLD_ORE broken by morganm at (x= -50, y= 30, z= -85, world=world) [t= 23sec / (d= 13 / b= 28) = r=49.0] [flagged] [Sat Jul 09 09:35:59 PDT 2011] IRON_ORE broken by morganm at (x= -54, y= 30, z= -95, world=world) [t= 19sec / (d= 10 / b= 24) = r=46.3] [flagged] [Sat Jul 09 09:39:09 PDT 2011] IRON_ORE broken by morganm at (x= 78, y= 34, z= -104, world=world) [t= 28sec / (d= 23 / b= 14) = r=16.8] [flagged] [cave?]
(ps. yes I was actually running an ore cheat to test locally, so this is "real" cheating and as you can see, it caught me)
Additional info
You'll also note the plugin has some minimal cave-detection. This doesn't query a bunch of blocks and looking for actual caves, instead it simply does a basic calculation of the distance vs. the number of blocks broken. If the distance is large and the number of blocks broken is low, it's probably a cave (since they didn't have to break many blocks to get between ores). This is not fool-proof, but I've found it to be pretty accurate and it helps weed out false positives at a glance.
As mentioned before, you won't see the time/block/distance/ratio text on every log entry. The plugin only prints it on block breaks that meet the minimum distance/block criteria as defined in the config file. This helps weed out the majority of block breaks in ore clusters, which are right next to each other. Thus if I just want to get a good feel for the ratio system and weed out the noise, another simple grep proves useful:
> grep 'r=' oreLog.txt [Sat Jul 09 03:35:15 PDT 2011] IRON_ORE broken by Player1 at (x= -786, y= 12, z= 1899, world=world) [t= 127sec / (d= 25 / b= 63) = r=318.8] [Sat Jul 09 03:36:35 PDT 2011] IRON_ORE broken by Player2 at (x= -152, y= 49, z= -249, world=world) [t=1202sec / (d= 3 / b= 403) = r=153182.6] [Sat Jul 09 03:40:45 PDT 2011] IRON_ORE broken by Player2 at (x= -153, y= 46, z= -252, world=world) [t= 249sec / (d= 5 / b= 147) = r=7178.4] [Sat Jul 09 03:42:25 PDT 2011] GOLD_ORE broken by Player1 at (x= -836, y= 13, z= 1893, world=world) [t= 418sec / (d= 52 / b= 86) = r=697.1]
A note on Performance
As I run a server myself, I'm keenly aware that every new plugin I install has a tendency to slow down the server and thus make my server lag and feel sluggish when at max capacity, so I take performance of my plugins very seriously. Minimal processing happens on the main Bukkit thread; it does the bare minimum checks as fast integer comparisons for an ore match and if found, pushes the info into a Queue where it is then picked up by a worker thread that all processing is done on. This means for those of you with beefy multicore systems, this plugin does it's best to take advantage of your additional cores and keep the Main Bukkit thread free to do it's processing in order to keep the server running smooth.
Does this work with groupmanager now?
@andrewkm
Despite showing as 'SEVERE', the "missing ebeans.properties" message is completely benign. I'm not sure why switching from "1.0" to "1.0.1" LogOres would change anything, I don't recall the LogOres implementation using ebeans at all.
In any case, it's not an error worth worrying about, but if you want to make it go away, just create an empty "ebeans.properties" file in your MC root and the Bukkit embedded Ajave ebeans container will not report the error anymore.
@andune
1.0.1 is causing the following severe on startup. http://pastie.org/4352757
Going back to 1.0 fixes this issue.
@Psithief
Ah, I didn't even see that pull request out there from @Sancta. Must have come in at a busy time for me so I didn't pull/test at the time and then forgot about it. I have no idea if it fixes the reported issues, but I've gone ahead and merged the request. If it doesn't fix the issues and you'd like to fix them and submit more pull requests, I'll be much faster about turning them around, so feel free. :) I also converted to maven so it should be much easier to download and build now.
New build released as v1.0.1, will syndicate whenever Bukkit guys get around to it, directly link here for now.
@andune
:/ ? There's been a pull request to fix it for 7 months before you even posted that. I'm completely lost.
Even if people on my server have the permission node to see notifications, they must have OP or it will not show them. Please fix this, thanks!
@andune
Kk, thanks for the reply. I'll just use file logging for now lol. I kinda forgot why I wanted to use MySQL in the first place anyway O_o
@badda2k
My initial intent for this plugin was to log to files, as there was already an abundance of DB-activity logging plugins out there (BB, LogBlock, Hawkeye and now Guardian).
However, someone really wanted logging to the DB and they wrote and pushed me a gitpull with DB logging enabled. I did tweak it a bit to fit into the structure of LogOres. So either I introduced a bug or the original author of that code had a bug, but in any case my motivation is very low to fix this as I don't use this feature nor was it really ever part of my original feature set. I included it only because someone was nice enough to write and share it.
All of my plugins are open source, so you are more than welcome to poke around and see if you can fix the issue and send me a gitpull back for others to enjoy. Here's a direct link to the DB logger implementation:
https://github.com/morganm/LogOres/blob/master/src/main/java/org/morganm/logores/Logger/DatabaseLogger.java
(Your other option, of course, is just to use file logging which works very well, I use it myself on my own server with some alert scripts and will certainly fix any bugs and keep it working as I find it an invaluable part of my anti-cheat toolkit)
Lol, so I guess the mysql bug will stay?
@giangylom
You can use the notify options to be notified real-time as violations occur, there are comments in the config.yml, documentation on site here and I've answered the question a few times so if you're having issues there's probably a few answers in the comments as well.
If you're referring to more of a way to run queries on past events through commands, then no, I won't be adding that feature. That's not to say that someone else couldn't add it (it's open source and I accept well-thought-out and well-coded git pulls), it's just not a feature I see as necessary since everything is already available in an easy-to-search log file.
Hi, thanks for the awesome plugin, but can i see the log in the chat? :3
I'm getting this error: http://pastebin.com/nN3hAXeW
I'm not sure what's wrong with it. :( All my other plugins are connecting and using mysql correctly.
@DrFusion
v1.0 in the file list is listed as supporting 'CB 1.2.3-R0.1'. Nothing significant has changed since then to break plugins. Why not download the latest and try it?
update the 1.2.4? dev builds/beta builds?
I forgot to mention this, but I have at least 50 players that may be x-raying. I have 3 thousand unique IPs that have joined my server :3 That's why I'm hoping there is some way to keep the current log, but be able to create a log that would be easier to examine for data. The current log is great for exact data, but not as good for viewing who needs to be watched more often :/
Is there a way to log only player names if they are flagged X amount of times or more? This way, I can have an easy to look at list of who I should investigate first.
@andune
Perfect! :) Thanks again for this great plugin. Also (this is not your fault), but I know this guy who found a mining technique that lets him find tons of diamonds. At the moment, he has more flags than an x-rayer does (flagged 34+ times). I just found it funny how he got flagged more than x-rayers. Aside from him, it does a pretty accurate job for finding x-rayers. :D
@badda2k
(finds all 2-digit+ "flagged" entries, excluding any caves) If you wanted just 20+, change the first [0-9] to [2-9].
@andune
I tried googling, but I couldn't find exactly what I'm looking for. What command would it be to do a search for something like "Find 'flag xQ' ,where Q is greater than or equal to 10"
@badda2k
That feature already exists: it's the UNIX command called grep. If you're unfortunate enough to be running this on a Windows server, install Cygwin.