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.
@Slappning
Slappning/Sancta: thank you for the DB work. Since I don't really have a use for this feature myself, it was my hope that someone who wanted it would eventually write the needed functionality, so that's great and I appreciate your work. :)
I did refactor the code to fit better into my intention for Logger implementations, which now fully maintains the capability for people to use multiple loggers at the same time. I've checked the refactored code into my repository, please feel free to check it out and test it. I'll let you maintain the code so if you give it a thumbs up I'll push a new release so others can take advantage of your work. Feel free to push me a git pull request if you make changes/fixes.
Hi andune Thanks for this great plugin. I added a DatabaseLogger-Class so you can switch between filelog and a mysql database. https://github.com/Sancta/LogOres
This is a great plugin. Thanks. I made a link to the log file on my web server so I can easily check it. I understand you can also output to a database, but have no idea how to make an interface for that. It would be amazing if somebody could come up with a nice HTTP front end that had password protection, sorting and a decent layout. Food for thought.
@MsohMage
MsohMage: I've done my best to detect "caves" as empty space where no mining has taken place and the player is finding ores. I tweaked the algorithm recently and noticed the accuracy went up in my own testing, that doesn't mean there aren't still false positives happening. Thus why the instructions say you should always login/TP to the locations to verify cheating actually took place. I do my best to improve the algorithms over time to minimize false positives, but they will never be perfect nor are they meant to be.
But, as you've also seen, it does a good job of exposing actual cheat behavior. You do still have to sort through some false positives, but I've found the amount of noise compared to before I was using LogOres is much less. If you want less noise, just log Diamonds exclusively, they tend to be very spread out and cheating is usually extremely obvious for them.
Regarding your request for notifications, that already exists. Check out the options in the config.yml.
i tried this for about a hour or so, it seems that walking in a abandoned mineshaft gathering the iron ingots and whatnot that lay around triggers the flag like a maniac. i got flagged like: [t= 54sec / (d= 33 / b= 30) = r=48.9] [flagged x1; ratio] on the 3rd iron i mined.
on the other hand it flagged another player like so: [t= 14sec / (d= 8 / b= 18) = r=98.1] [flagged x5; ratio paranoidDiamonds]
and when i tp'ed to it, certainly enough.. there it was, a 1x2 straight tunnel with few ups and down steps. I guess it works like a charm as long as false-positives are looked into first.
Now, the request: can we get a message saying "nick was flagged Xtime on X Y Z" that would only go to Moderators and Admin groups? (or should i install another plugin to do that?)
I can only say that this plugin is EPIC. I used this for the whole week without one single problem. Excellent job!
@andune Oh... Ok thanks i just installed it. Great plugin not like FoundDiamonds which have kept spamming my screen for the past few weeks...
@th3controller Scanning for torches would be CPU-intensive and LogOres accomplishes the same through the logLightLevel parameter. No torches? No light. Set 'logLightLevel' to true and then set 'flagging.flagWhenZeroLight' to true and you'll end up with flagged entries (and they'll say 'nolight' as the reason) when someone is mining in pitch black (ie. no torches). Look in your config file for descriptions of the various flags, or read them online here: http://dev.bukkit.org/server-mods/logores/pages/config-yml/
You sir are a master genius! Can you also add torch verification for example: "thecontroller is mining through a cave with XRAY activated and is using a transparent texture pack. However he has forgotten to put torches. Super Mega Awesome LogOres has scanned the area around the player if there are torches and Supah MEGA Awesome LogOres has detected there are no torches of a radius of 10 blocks! LogOres has verified he is a qualified xrayer and is now reporting to a Admin." So if you think this is a good idea can you pretty please cherry on the top add this to the plugin and add a interval on how many minutes the plugin scans for players with no torches.
@bradgillap
I can't see myself adding this capability, honestly (email directly from plugin). Also on my production server, despite my efforts to weed out most of them programmatically, I still see enough false positives from legitimate users that it seems strange anyone would actually want to be mailed all of those.
I'd say your best bet is to write a script to do the scrub/sending for you. Or if someone was so motivated and they wanted to write a clean implementation and push me a git-diff, I'd consider merging the functionality.
This plugin has evolved quite a bit since your first edition. Is there any way to offer sendmail to notify me via email when a flag has tripped?