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.
How often does this update the logs? My friend and I were on the server for an hour, and it shows the first 5-10 minutes of us playing and all the ores we mined, but I know that many more were and it doesn't show up on the log. Does it only record on the log every so often? Is there a way to change that? Thanks
Does this work with Netherite on 1.16.5?
works well on 1.8 find and i like how you can add the ores you want to log some other ones dont let you edit much
The MySQL structure for the ratio value is not correct for the max possible value. You can get errors. It should be increased to accept all values that LogOres is trying to write. I simply set mine to INT now and it's fine.
@andune
Ok, thanks for the info :)
@Hangar
The first warning is benign. It's annoying, but nothing breaks because of it.
If it really bothers you and you're NOT using the LogOres database logging, then just edit the LogOres plugin.yml (inside the JAR) and set database: false.
Ideally this would be something a plugin author could control dynamically (rather than being hard-coded in the plugin.yml), so I would just not load/use ebeans if you aren't using the database. I wrote a Bukkit pull request over a year ago to allow exactly that, the Bukkit devs closed it as "will not fix", so they're happy with the hard-coded solution they offer and have no interest in improving it.
I was getting this warning every time I loaded my server:
2013-07-30 10:02:14 [WARNING] No Entities found in ClassPath using ClassPathReader [com.avaje.ebeaninternal.server.util.DefaultClassPathReader@dc188aa] Classpath Searchedfile:/H:/mc/craftbukkit.jar
Someone in a Bukkit forum post I found said to add this line (ebean.search.jars=craftbukkit.jar) to my ebeans.properties file, but when I do, LogOres (only, out of 60 plugins) starts throwing this error on start:
http://pastebin.com/Sej7ifzw
So I guess I'll opt for the first warning and keep LogOres working?
Um suggestion: make it so when people download, the notify config is on? I was so curious as to why logores wasnt working then i didnt notice notify was false, wouldn't it make sense for it to be true when you download it? XD Just a suggestion
Could you perhaps add a permissions list to this page so that I don't have to search in the changelog every time I forget them? xD Just a friendly request. And, as a side note, in which direction is Notify working? Do you give the players that you want to watch notifications from it or do you give it to the Admins so that they are notified?
@Skingn
Sure, I updated the file description to show compatibility with 1.5.2; the file itself hasn't changed and still works just fine, no updates necessary.
Can you update for 1.5.2
@bostonianb
Don't believe there are any breaking changes related to LogOres. My server just updated to 1.5 a few days back and uses LogOres, it seems to be working just fine.
@guyag
Any word if it breaks with 1.4.7 or 1.5?
Also any fixes if it does?
@andrewkm
He's aware, and I'm guessing that the plugin is awaiting approval in the bukkitdev process.
1.4.4 http://pastie.org/5379303
@andune
Great to hear that this will be updating. I have been using this plugin for months and I would hate to have to switch.
Great plugin, thanks.
@guyag
Yeah, this plugin like my other (HomeSpawnPlus) were written before Bukkit added getLogger() to the Plugin API (so have had that method for longer than Bukkit has) and the most recent Bukkit v1.4.4 version they made it final, which broke the build for these plugins. I'll get an update published, it's any easy fix.
Regarding dependencies, use maven, that's what it's for. The only two commands you need to build this plugin are:
Broken on 1.4.4, you override the default Bukkit logger (.getLogger()) http://pastie.org/5378220 full error.
Edit: pushed (untested) code to your github. I don't have the various permissions jars to build against unfortunately, so can not test.
@Bronypowerr
Works on 1.3.2, and 1.4.2.
Y U NO UPDATE TO 1.3.2?
Please do <3 This plug-in is super useful