GreylistVote
For a while I have been running the Ellitopia.net server and have had great difficulty finding an effective way to operate a greylist.
A greylist is similar to a whitelist, except players are allowed to log into the server but without build rights. When the player is trusted, build rights can be released.
The difficulty I had was allowing the player to be promoted while there were no admins or mods online to manually issue the promotion. I tried a few voting systems, but I never really found one that did exactly what I wanted... so I thought I would make my own!
So here it is, GreylistVote, the greylist management plugin allowing players to express their trust in a player using a vote command. You can customise how many votes are required for a player to be successfully promoted.
As of v1.1 the system works on a reputation based system. a /greylist vote increases reputation by 1 whereas a /griefer vote reduces it by 1. If the players total reputation is at or above the "required_votes" level they can build, if the drop below it they can't. Players with the greylistvote.approved permission are always approved, even if black-balled by users (use for Mods/Admins etc)
New to 1.3: /glv clearserver and /glv clearall can be used to remove Server votes or ALL votes respectively from a player.
New to 1.5.2: Players can now vote for offline players
Commands
/greylist [player] : Vote for a player to have build rights
Alias : /gl /trust
/votelist {player} : Show who has voted for the player
Alias : /glvlist /rep
/griefer [player] : Vote for player to be black-balled for griefing
Alias : /distrust
/glv : View available commands
/glv setrep [reputation] : Set the required reputation level to gain build rights
/glv toggle ["pvp"|"approvedvote"] : Toggle true/false config options
/glv clearserver [player] : Remove all 'Server' votes from this player
/glv clearall [player] : Remove ALL votes from this player
Permissions
greylistvote.* : Approved, with access to ALL commands
greylistvote.admin : Access to /glv setrep
greylistvote.vote : Player can use /greylist (or /gl)
greylistvote.griefer : Player can use /griefer
greylistvote.approved : Player is approved for building (automatically added to approved players)
note: Only use this in permissions config to FORCE approval despite any Black-Ball votes when the player logs in
Installation
- Copy the .jar file to your /plugins folder
- Reload your plugins/server
Configuration
- Edit the config.yml file which is created in the /plugins/GreylistVote folder
- Set required_votes to how many votes a player needs before being approved
- Ensure that at least the number of players needed to gain approval have the greylistvote.vote and greylistvote.approved permissions (or greylistvote.*)
- Reload your plugins/server
If you have "griefer_votes" in your config.yml, this is no longer needed.
Notes
As of 1.1, the Console CAN vote, and it's vote overrides any other votes in the system, so:
- If the console uses /greylist the player is automatically allowed to build and all griefer votes are removed.
- If the console uses /griefer the player automatically loses build rights and all greylist votes are removed.
Console votes appear as "Server".
As of 1.2, a Server approval forces reputation to whatever is required for approval, and a Server Black-Ball forces reputation to -1.
As of 1.3, issuing a /griefer vote removes any /greylist votes the player made previously (and vice versa).
As of 1.5.2 You can now vote for offline players
As of 1.5.5 you can set the config option "allow_all_approved_to_vote" which ignores the .griefer and .vote permissions to allow ANY approved player to vote. This and the PVP option can be toggled in game using "/glv toggle [pvp|approvedvote]"
Future Plans
- Allow custom commands on approval/black-ball
Donations
To show your support and help me justify to my wife why I spend so much time on Minecraft, please donate using the Donate button in the top right corner of this page!
Thank you
Other Projects
View my profile page for details of my other plugins.
Suggest a Project
Got an idea for a project? PM me and I'll give it a look!
Does this plugin still work? I tried runing it and /trust is working but when anyone does /distrust or /griefer it says "you caanot vote for yourself" even though we are not voting for ourselves.
IE I vote to trust you and now you can build but if I vote to distrust you I get "You cannot vote for yourself."
I don't think this is a permissions issue as I can't distrust even playing my op account which has all permissions.
Can you turn this into a Repuatation system.
Plugins like: http://dev.bukkit.org/bukkit-plugins/reputation/ and http://dev.bukkit.org/bukkit-plugins/reputation-system/ are nice but are not useful.
They don't have localization and fix of bugs. I like your codding logic and configireubility. If you look into this kind of system it would be great! Just modify this plugin a little, throw out the build permission part and it's ready to go!
I've just uploaded v1.5.5 which fixes some bugs in the previous version and adds a few new features. Most notably:
Any bugs? Please post tickets so that I can easily track any issues that need attention.
Enjoy!
Hello! I'm using this plugin on my server together with GroupManager. I'm having some trouble with the PvP not working properly. I suspect it's the option where non whitelisted users shouldn't be allowed to PvP that's messing stuff up. I've tried setting the option to false, but that doesn't help.
Players are able to use potions and bows, but no swords or fists. Moderators and Admins however, have the ability to PvP, because they were given the greylistvote.approved permission.
Is there a way to solve this or does the plugin need updating? Is there another plugin that has the same functionality that is recommended to use instead?
I've noticed a small issue while using PermissionsEx.
If the player has joined for the first time, it won't let you /trust them. It says "Player "playername" not found!". But, if they relog, and then we try to /trust again, it seems to work. I think it's just a way that PEX works.
EDIT: It is great though, works well. (Besides the small problem!)
Update: My plugins are currently on hold while we wait for 1.3, since the 1.3 update will more than likely break large portions of most of my plugins! Sorry for the delay and please stay tuned for future releases.
You should really think about hooking this into permission plugins a bit more. Or having it work that you can allow players to only build in one world while greylisted, and then be allowed more commands/worlds once the have been voted in
<<reply 630456>>
I believe GreylistVote wants you to have/run Java 7 instead of 6 ;-)
Would you be able to toggle the usage on /trust? I run GriefPrevention, which uses that to add people to claims.
Also, receiving this error when loading it on my test server:
Could easily be me being an idiot and missing a dependency, but didn't see anything you posted. Only other plugins I have on here are Herochat, Vault, and PEX.
D'oh, how stupid of me.. you are so right :) This changes everything for me, and also for the people on my LAN ;)
Thank you so much for creating those wonderful plugins ellbristow!
@ThisUsernameIsMine
Providing you set permissions correctly, new users cannot upvote themselves, since they do not have permission to vote unless you give them the greylistvote.vote permission node.
The only way I can see this being possible is for the player to get one account approved so it can vote, re-log in the second account, log back into the first, vote for the second account, then re-log again into the second account... and even then they only have one vote, so still do not get build rights.
To avoid this, I suggest setting up a non-default group with the greylistvote.vote permission node to move approved players to after they have had build rights for a while. Personally I think that is a lot easier (and fairer) than restricting multiple accounts from the same IP.
As you say, you could easily be stopping legitimate players from logging in... such as on my server where we have 3 brothers who all log in from the same IP address.
In summary... sorry, I won't be adding an IP limiter. :(
Hello :)
Is it possible to implement a connection-limit coming from the same ip address. This could (would) be handy when griefers try to login using multiple clients to upvote themselves.
I know this might also lock out fair players but i would love to see this as a configurable option. Thanks!
(other plugins that have the same features are also welcomed)
v1.5 uploaded pending approval
I've added an option in the config.yml to stop unapproved players from being able to hurt other players. (They can still be hurt though >:) )
This build has been (albeit briefly) tested on the new 1.1-R3 RB
Tested: Working with CraftBukkit 1.1-R1 (#1818)
Version 1.3 has just been uploaded (pending approval). It addresses the issues raised by @techdesign and re-words some of the messages to better reflect 'reputation'.
I also added /trust as a new alias for /greylist and /gl
Edit: Oh, and I moved /clearserver to /glv clearserver, and added /glv clearall. Use /glv to see all the commands.
@techdesign
Two good points... I'll be sure to take a look at them.
I'm also going to change the chat messages to something along the lines of:
x increased your reputation
x decreased your reputation
Your reputation is too low to build
Sound good?
Looking much better!
I started my tests with a new config of GreyListVote. The first thing I noticed is that the check for greylistvote.approved did not work for my main user when they logged on. I double-checked to be sure they had greylistvote.approved as a permission.
The next thing I noticed after playing with it is that when vote for someone, then /griefer someone, my name appears in both lists. It seems like it should only be in one list. So if I am in the vote: list and then for to blackball someone, my name should be removed from the vote list, and added to the griefer list.
@techdesign
And now I've uploaded v1.2 which adds the /clearserver command and tweaks some of the /votelist messages.
@techdesign
OK. I found the problem with the reputation calculation for the first vote (the leading , in the vote list), and fixed it.... hoever...
Reputation (and the resulting permission) is now calculated on player login (this causes much less server load than checking on block interaction), so the greylistvote.approved permission is now ONLY required if you want to FORCE approval despite black-ball votes (for Mods/Admins etc). I haven't FULLY tested how this works with players being black-balled in game when they have the approval permission. Feel free to test it on your own server and let me know.
Quick thought here, please feel free to completely disregard this, as my last programming experience was several years ago in college.
It appears you might have issues with your "approved" and "blackballed" arrays (not sure if those are the right names). Once those get ironed out, I'm not sure you need to worry about greylistvote.approved.
You already have persistent storage of someone's reputation in your users.yml file, so as long as that is continually updated when votes happen, you could simply block place and destroy events based on subtracting the number of elements in the "blackball" array from the number of elements in the "approved" array. If the answer is at or above the required reputation level, let the block interaction happen, otherwise, block it.
I don't know what kind of a load this would create versus your simple check for the presence of a permission. If computation checks are a lot more intensive than permission checks, then your current method is probably better.