XRayField
Overview
This plugin uses a sophisticated mathematical algorithm to diagnose x-raying players on your server based on their trajectory when they are mining around diamonds. Based on the principles of vector calculus and physics, we present an anti-x-ray system that even Newton couldn't turn down! Check out the video below to see how to use it!
Video
But How Does it Work???
To learn more about the math behind this plugin, check out this slide show.
Command Documentation
/xray [-as] scan [null] | Returns a sorted list of the most likely cheaters on your server. By default, this command will compare all players against trusted miners, but a custom numerical null hypothesis (e.g. 0.006) can be specified if there is no trusted mining data. |
/xray [-as] stats <player> | Shows summary of mining statistics for a player. A high mean power value is indicative of cheating. |
/xray [-as] test <player> [null] | Performs a test for x-raying on the specified player. By default, this command will compare all players against trusted miners, but a custom null hypothesis (either numerical or a player name) can be specified if there is no trusted mining data. |
/xray [-r] trust [player] | Adds a player to the list of trusted miners. Typing /xray trust on its own will display the current list of trusted miners. The -r flag can be used to revoke trusted mining status from a player. |
The -a flag can be used to specify a test of only archived data (i.e. data that saved in the log files but not from the current session), and the -s flag can be used to specify a test of only session data.
Permissions
This plugin supports the following PermissionsEx nodes:
xray.stats | Allows player to view player data and use scans and tests |
xray.trust | Allows player to view and edit trusted miners list |
xray.hack | Stops the plugin from taking automatic action against a player who is allowed to hack (UNIMPLEMENTED) |
Customization
The config.yml file lets you change what types of ore are kept track of by the plugin. To add a new type of ore, add it to the "sources" list. The default sources list reads as follows:
sources: DIAMOND_ORE: flux: 1 ceiling: 16
As the config above shows, the only ore tracked by default is diamond. The "flux" associated with diamond ore is the attractive strength of the force field that the plugin simulates around diamond blocks. Generally, ores that are more likely to be xrayed (i.e. more valuable) should have higher fluxes than less valuable ones. For example, you might give diamond a flux of 6 and iron a flux of 1. The "ceiling" attribute refers to the maximum height at which the plugin will track a certain block type. The maximum spawn height of diamonds is 15, so the ceiling for diamonds is 16.
Troubleshooting
Using the /reload command has been known to cause issues with some versions of XRayField. If you are getting console error messages after using /reload, try restarting the server and they should go away. If you are resetting a map, consider removing all CSV files from the /plugins/XRayField/logs folder. If you see "null" listed on your trusted players list after resetting a map, go into your config.yml and manually delete player UUIDs.
What to Do if You Like Our Plugin!
Subscribe to our channel!
Official XRayField Server
ladybug.zoo.cs.yale.edu
@Goooooogle
I appreciate your feedback! I haven't pushed any updates recently, but I may try to update the UI in the future.
I do hope this plugin is still in development. I absolutely love the concept, I appreciate intelligence that went into it. If I'm going to be honest one thing that could be improved is user-friendliness as some functions of the plugin lack explanation. For instance, the alphas section of the config.yml isn't really explained at all (what do the numbers actually mean etc.) or how the power values could be replaced or assigned with verbal descriptions to help people understand them better.
Aside from that, I applaud you for investing the brainpower into coming up with a clever solution to an ever-evolving problem.
@The_PC_Tech_Guy
The reason why you're getting weird scores is because the default behavior of /xray scan without arguments is a little odd. It compares players' data against a trusted miners' list, which I've actually found doesn't work that well unless you have a lot of trusted miners. In the next version of the plugin, I'm going to set the default behavior to using a null hypothesis value specified in the config(0.0065 or something like that), but in the meantime, the best way to deal with that is to use
/xray scan 0.0065 instead of /xray scan
Just ran a /xray scan, and got scores of 10 for players which haven't mined a block :/ Also lots of NPEs when running commands with a missing arg or so.
I'll see if I can fix it but since I'm using mode 2 antixray and haven't been getting many complaints about it I might not need to use this plugin. (I'd also be more inclined to fix/submit PRs if this used maven.)
@The_PC_Tech_Guy
Yeah, something like that could work maybe. Although I'm not sure if the results would be better than just using the player velocity, which seems to have been pretty reliable so far.
@waco2
Ah, thought you were just plotting the player's location, not their velocity, otherwise could use consecutive block breaks (and interval between them) + their location to achieve the same effect?
@The_PC_Tech_Guy
Good to know. The problem with using BlockBreak imo is that statistic the plugin is calculating to assess x-raying depends on the player's velocity vector during the event. Thus, if the plugin used BlockBreak instead of move events, players could easily break a block while standing still, move, break another block, etc. to get around their movement towards diamonds being detected.
At the same time, there would be some advantages to using the BlockBreak event since line-of-sight movement towards diamonds through caves/ravines would be ignored.
@waco2
The player hasn't joined the server yet - no need to load data if the player hasn't connected. If another plugin denies a player from joining, PlayerQuitEvent wouldn't be called. Also, I'd collect data on blockbreak, instead of playermove.
@The_PC_Tech_Guy
To be honest, I didn't realize there was any difference between the two events. Is PlayerJoinEvent more reliable? That would explain some issues I've seen.
Also, you can find the source here: https://github.com/viking-sudo-rm/XRayField. I won't have much time to work on the plugin for the next couple months since I'm in university, but feel free to make your own version/push anything to my repository!
Why are you using PlayerLoginEvent vs. PlayerJoinEvent? Also, do you plan to open source?
@The_PC_Tech_Guy
The difference is that "alert" prints out to the console/server log, whereas "warn" warns the player who is mining that they have crossed the threshold. Hope that helps :)
Hi, could you explain the config a little bit more? I want to make sure that no action is taken on players, suspect or not, but to simply monitor and report (either in log and/or in-game). There's some values under config node "alpha" that seem to indicate this, and I'm not entirely sure what they do, at least for alert and warn.
@2008Choco
Thanks bro! I appreciate the kind words.
Holy crap. Okay it's two in the morning for me and im just browsing plugins. I see the word X-ray in a plugin and I have to view it...
Mistakes were made. I think my brain just melted over the sheer genius of this plugin. The math for this plugin is ingenious. The theory out behind this project just blows me away and I am impressed that you put about 850kB of work into this plugin so far. Mad props to you man. Keep up the fantastic work. I hope people see this plugin and download it. Very very very smart
@justin393
It shouldn't be that intensive. The only somewhat demanding part of the plugin is when a scan command is run, and that only happens when an admin issues the command (very infrequently). The tick-by-tick collection of data while players are mining should be negligible.
Any specs on server intensity such as lag?