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.
Re: mysql, I have a few open tickets on that, I believe it's broken at the moment. That code was sitting checked into the repository for a long time and just got released with the latest update, so I can't say it's been well-tested and you guys have done a great job finding some problems that need to be fixed. :)
Re: the 0.9 "WEPIF" error, this is a problem with LogOres being coded against the latest version of WorldEdit/WEPIF, where the WEPIF classes changed. So now if you're running an older version of WorldEdit, you'll get that error. I've fixed the error in my other plugin (HSP) by disabling WEPIF support if you're on an old version of WorldEdit, I'll add that to LogOres for the next version. For now, your two choices are: upgraded to a version of WorldEdit newer than build #606 (I believe that's 5.0 series+), or edit your LogOres config.yml and just comment out the "wepif" line in the permission setting.
kozzy68: please open a ticket with your request, or I'll lose track of it. Certainly seems reasonable.
Installed it, restarted the server, does not log anything. Config file was created, no logfile. Changed to MySQL mode, created the table manually due to the SQL error and also there, no entries.
Now I get these errors:
22:53:27 [SEVERE] com.mysql.jdbc.MysqlDataTruncation: Data truncation: Out of range value adjusted for column 'x' at row 1 22:53:27 [SEVERE] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3591) 22:53:27 [SEVERE] at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3525) 22:53:27 [SEVERE] at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1986) 22:53:27 [SEVERE] at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2140) 22:53:27 [SEVERE] at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2620) 22:53:27 [SEVERE] at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2570) 22:53:27 [SEVERE] at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:779) 22:53:27 [SEVERE] at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:622) 22:53:27 [SEVERE] at org.morganm.logores.Logger.DatabaseLogger.logEvent(DatabaseLogger.java:130) 22:53:27 [SEVERE] at org.morganm.logores.LogEventProcessor.logEvent(LogEventProcessor.java:589) 22:53:27 [SEVERE] at org.morganm.logores.LogEventProcessor.run(LogEventProcessor.java:568) 22:53:27 [SEVERE] at org.bukkit.craftbukkit.scheduler.CraftWorker.run(CraftWorker.java:34) 22:53:27 [SEVERE] at java.lang.Thread.run(Thread.java:722)
Unable to start up with v 0.9 of this plugin...
Hi I have tiny suggestion to make it lot more easy for excel format users to read logs and make filters. 1 Is it possible to change excel log file extention to .csv ? This way it will just take one double click to open log in excel or ms access. (access can read only certain predefined extentions for securyty reasons for data imports .data is strange)
2 is it possbile to remove semicolon from this log message (|flagged; ratio|) and change delimiter from | pipe to comma ? This would alow open log witch automaticly formated fields.
@andune
Thank you, great job as always :)
@w000rm
Hmm. I thought I had an option to disable flagging if in cave, but I guess not. I think it's because originally the cave flagging wasn't very robust so I err'd on not letting people ignore cave alerts since I was afraid it might miss cheating.
Since the cave checks are more robust now it would make sense to allow people to have cave entries not be flagged at all. I'll add that as a configurable option in the next version.
Great plugin, I have been using it since 1.7.3 if I'm not wrong.
However, I just noticed an issue: It flags EVERY ore mined in a mineshaft. I mean, it does say it's a [cave] but all my users who mine into mineshafts get flagged by your plugin. Is there a setting in the config I should play with? Or would an additional mineshaft check have to be added?
Thank you :D
Alright thanks :) I'll wait around a bit for the new version.
@andrewkm
You can ignore that error, though I will fix it in the next version.
Regarding performance, LogOres currently runs on a 5-second cycle so it's basically writing to disk once every 5 seconds and even that is just going through standard Java I/O so it is probably being cached by your OS and physically flushed to disk even less frequently than that (assuming you have RAM to spare). If you have disk I/O problems, it's highly unlikely this plugin is contributing in any significant way to them.
@morganm
1 Bug/problem 1 question:
Issue: Seeing this on server startup with your newest version
2011-12-23 12:43:29 [WARNING] [LogOres] Could not load build number from JAR
Question:
Do you recommend to use mysql for better performance as opposed to keeping the logs on a different harddrive (Not the one server is on)
@rbos
Thanks for the report. I think I see the issue and will work on getting a fix posted soon.
Love the plugin. Against the latest NoLagg though:
java.lang.IllegalAccessError: Synchronized code got accessed from another thread: org.morganm.logores.LogEventProcessor at com.all.bukkit.threadcheck.ThreadCheck.check(ThreadCheck.java:83) at com.bergerkiller.bukkit.nolagg.meta.WorldMetaData.get(WorldMetaData.java:48) at com.bergerkiller.bukkit.nolagg.meta.ChunkMetaData.get(ChunkMetaData.java:38) at com.bergerkiller.bukkit.nolagg.meta.ChunkMetaData.get(ChunkMetaData.java:35) at com.bergerkiller.bukkit.nolagg.NLWorldListener.onChunkLoad(NLWorldListener.java:24) at org.bukkit.plugin.java.JavaPluginLoader$52.execute(JavaPluginLoader.java:626) at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:58) at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:339) at net.minecraft.server.ChunkProviderServer.getChunkAt(ChunkProviderServer.java:92) at org.bukkit.craftbukkit.CraftWorld.getChunkAt(CraftWorld.java:101) at org.bukkit.craftbukkit.CraftWorld.getBlockAt(CraftWorld.java:69) at org.bukkit.craftbukkit.block.CraftBlockState.getBlock(CraftBlockState.java:163) at org.morganm.logores.LogEventProcessor.processEvent(LogEventProcessor.java:217) at org.morganm.logores.LogEventProcessor.run(LogEventProcessor.java:542) at org.bukkit.craftbukkit.scheduler.CraftWorker.run(CraftWorker.java:34)
I run this on my server and it's working fine on latest dev builds. I'm sure it runs fine on the recently released RB, when I get a chance to upgrade and confirm no issues, I will update the file info here to indicate it is a supported build.
EDIT: confirmed to be working fine on CB 1.0.0-R1 (build #1597)
I don't know if this plugin needs to be updated any time soon, but it would be a true shame if it were to go inactive. This plugin is our shield from xrayers and it is tremendously effective
you should probably provide a separate section with the permission nodes, few as they are, for easy reference.
@andune
Oh my, that's an awesome config [and therefore, plugin] you have there. Extremely detailed catch'em all boundries.
Also.. Now i'll have to x-ray my server so i can get a glimpse of what a flagged entry looks like in this new logores.txt because... no more entrys were added since i instaled the new version. I'm thinking i had a butload of false-positives but someone had to be using xray. or maybe i'm just negative. x)
I mean, if you focus your xray'ing on [cave] system, it gets a little hard to weed'em out. Either way, nice indeed.
@MsohMage
Hmm, thanks for pointing that out, I forgot to update the ChangeLog page here when I uploaded v0.8 on September 10.
Regarding light logging, yes, look in the config file, there is an option for it "logLightLevel" and also "flagging.flagWhenZeroLight" if you want 0-light mining to show up as flagged.
Hi. Something's wrong. Main page says last update was made @ 11 September whilst the changelog says the last update was september 5th.
Eitherway, i just wanted to know if [the last version] has any way to see how much light was surrounding the found ore? After using this plugin a bunch of time i came to think that that might help distinguishing false-positives.
@qazzi
It was written with performance in mind, especially if you have multiple cores. Joy (admin of BuxVille) was using it at one point, no idea if he still is anymore. In any case, give it a go, it should have a much lower impact on system resources than most other plugins you might install and is the lowest impact way to catch cheaters that I know of from the options that are out there. Feel free to let me know if you find any issues.
Anyone running this on a server 75+ - I'd like to catch xrays and this may be best - server performance wise - way to stop it.
anyone? :)