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.
Needs an update for 1.3.2
@andrewkm
Yes. Only DB logging depends on the database flag.
Alright thanks I have made it false in plugin.yml for now :) Btw will my file logging still work?
@andrewkm
I've submitted a pull request to Bukkit that allows me to fix this issue by not turning on the database if you're not using it:
https://github.com/Bukkit/Bukkit/pull/680
When/if it gets merged, LogOres will take advantage of the functionality to avoid the login spam and overhead associated with loading ebeans if you're not using it.
@andrewkm
Hmm. It would be nice (since DB is optional for LogOres) to not load the ebean server if the DB is not being used. Unfortunately, last I looked, Bukkit gives no control to developers for this: ebean loading is controlled by the plugin.yml "database: true" property, with no ability to override it at runtime. So a plugin is compiled and distributed with this set to true or false.
If you're not using database logging for LogOres, then the easiest way to disable the error is to open up plugin.yml (in the JAR) and set "database: false". Another option is just to create an empty "ebean.properties" file in your top level minecraft folder (same level as server.properties). It's not a required file for Bukkit ebeans, but the embedded ebean server annoyingly whines about it on startup if it's not there.
LogOres giving this off in startup on latest CB RB http://pastie.org/4684531
Im assuming its due to: https://github.com/Bukkit/CraftBukkit/commit/c47257b412327a28e7c114d3639569f2b4347600
But I could be wrong. LogOres works perfectly fine; just that startup warning is quite annoying.
Is there a permission node to give a player so that they are NOT logged? Is this even possible with this plugin?
I ask because I run a Tekkit server and would like to be able to have LogOres ignore the "fake players" that are set for each of the Tekkit mods (ie [BuildCraft], [Redpower]. I don't want my logs filling up when someone uses a quarry or similar machine.
I realize you probably don't support Tekkit per se, but I could make it work if I can give a permission node to a player so that LogOre will ignore all actions from that player.
@GioboiMC
GroupManager is not directly supported, however Vault is. So using Vault is one option.
The other option is that GroupManager should support superperms and if you do nothing else, LogOres will use superperms so it should work.
I don't offer permission troubleshooting help. If you can show output that confirms the player has the expected permission and that you are using the latest version of Vault, then I can look into a possible bug (which I don't expect since the Vault permission checking code has been stable for a long while and works fine on my server).
Seems to be op only for me using groupmanager :/..
Maybe it is just me, but is there a list of permission nodes anywhere? I can't seem to find them, lol.
@GioboiMC
Did you add logores.notify to the group you want to be notified?
Edit: Checked date on comment. Hopefully you resolved your issue.
just started it up and got this message:
2012-08-09 21:48:46 [INFO] [LogOres] using SUPERPERMS for permissions 2012-08-09 21:48:46 [INFO] [LogOres]version 1.0.1, build 6 is enabled
Let's hope it works.. I've had trouble seeing notifications and it just putting them in the logs since the R5 total api rebuild months ago i forget what update it even was.. Maybe the end of 1.1.
I do have vault installed (should have mentioned that), however I'll try what you're suggesting with the superperms for now.
@GioboiMC
I do. GroupManager is not a valid option for permissions. I should code it to read a more specific error, but the fact that it is erroring is no surprise. Either install Vault (which will then work with GroupManager) or just leave it as 'superperms' (which GroupManager should support natively).
Last part of my post below didn't paste right but you probably get the gist of it.
I was messing around with the settings.. I think it has something to do with the permission system thing at the bottom of the config. What should mine say for that last part? I'm using GroupManager and I got this error:
2012-08-09 20:52:18 [SEVERE] Error occurred while enabling LogOres v1.0.1 (Is it up to date?) java.lang.NullPointerException at org.morganm.logores.util.PermissionSystem.getSystemInUseString(PermissionSystem.java:109) at org.morganm.logores.util.PermissionSystem.setupPermissions(PermissionSystem.java:209) at org.morganm.logores.util.PermissionSystem.setupPermissions(PermissionSystem.java:144) at org.morganm.logores.LogOresPlugin.initPermissions(LogOresPlugin.java:181) at org.morganm.logores.LogOresPlugin.onEnable(LogOresPlugin.java:112) at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:217) at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:365) at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:381) at org.bukkit.craftbukkit.CraftServer.loadPlugin(CraftServer.java:265) at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:247) at org.bukkit.craftbukkit.CraftServer.reload(CraftServer.java:567) at org.bukkit.Bukkit.reload(Bukkit.java:183) at org.bukkit.command.defaults.ReloadCommand.execute(ReloadCommand.java:21) at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:168) at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:492) at net.minecraft.server.NetServerHandler.handleCommand(NetServerHandler.java:878) at net.minecraft.server.NetServerHandler.chat(NetServerHandler.java:825) at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:807) at net.minecraft.server.Packet3Chat.handle(Packet3Chat.java:44) at net.minecraft.server.NetworkManager.b(NetworkManager.java:281) at net.minecraft.server.NetServerHandler.d(NetServerHandler.java:109) at net.minecraft.server.ServerConnection.b(SourceFile:35) at net.minecraft.server.DedicatedServerConnection.b(SourceFile:30) at net.minecraft.server.MinecraftServer.q(MinecraftServer.java:583) at net.minecraft.server.DedicatedServer.q(DedicatedServer.java:212) at net.minecraft.server.MinecraftServer.p(MinecraftServer.java:476) at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:408) at net.minecraft.server.ThreadServerApplication.run(SourceFile:539)
I was very confused at how to do this last part of the config, but this is what mine looks like as of now:
@GioboiMC
My question was leading. Too many people come onto these forms and ask "does it work with <insert version here>?!". Put some effort in, try it out. Most Bukkit upgrades are seamless and when they aren't, you'll typically see error reports in the plugin comments or tickets, or developers saying they are working on a new version.
Hint: My own server is on 1.3.1 and I wrote and use LogOres; it's working fine for me and I have not updated it.
(However, I do not run GroupManager and I can make no promises that it works. LogOres will hook Vault and Vault provides an abstraction over GroupManager. If you're getting a stack trace that looks to be related to LogOres, feel free to open a ticket with the details and I will look into it)
It doesn't seem to work whatsoever with 1.3, groupmanager hasn't seemed to work since the R5 total rebuild a while back. I can keep it running and see if it spits out an error for ya.
@GioboiMC
Did it break in 1.3.1? Did you test it? Do you have an error and if so did you open a ticket with the information needed to troubleshoot the error?
GroupManager should either be supported out of the box by virtue of using superperms (which LogOres uses as the default) if the GroupManager folks have done things right; my latest understanding is they have. Your other option is to install Vault which LogOres will prefer if it is installed, and Vault provides an API to other permissions plugins, including GroupManager.
Please update this for 1.3, and also update it to work with essentials groupmanager like it did a while back. Thanks so much for this plugin, it's the only good xray detector out there..