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!
Okay, fresh setup using 1.13. I set the required_votes to 1 due to testing this alone.
Two players online - techdesign, user1. techdesign is in a group with greylistvote.*. user1 is in the default group. user1 cannot build and gets the "not yet approved" message.
techdesign - /votelist user1
results: user1 has not received any votes; current reputation: 0
users.yml = empty
techdesign - /greylist user1
results: your greylist vote for user1 has been accepted
user1 sees: techdesign voted for you to be greylisted
users.yml =
user1 still cannot build
techdesign - /votelist user1
results:
And user1 still cannot build.
I'd be happy to try this with a different permissions system in case that is the problem. What are you using and I can pop that in my test server quickly.
@techdesign
Quick update, I've submitted a forum post to bPermissions to ask if I am doing something wrong. I'll let you know what I find out.
@techdesign
I just added it to the GitHub downloads page for you :)
https:github.com/ellbristow/greylistVote/downloads
@ellbristow
Can I get 1.1.3 from your github page? I don't know if github has binary .jar files or if I need to wait for it to show up here.
@techdesign
:) version 1.1.3 was uploaded 2 hours ago and is awaiting approval. it fixes the null problem and counting the first vote as 2.
With the stop and restart losing permission... not sure about this one... I will look into it.
Try it with 1.1.3 and let me know if you still have the same problem.
Okay, I'm trying to test this. I have 4 people online. I am a member of admin, which has greylistvote.*. The other 3 users are "new" and members of the default group, which has very basic commands.
I set required_votes: 2.
We log on and User1 tries to dig. They receive "You are not yet approved to destroy blocks!". I type: /votelist User1 and it says "Current Reputation: 0".
I type: /greylist User1 and it tells me my vote has been accepted. I then do /votelist User1 and it now says Current Reputation:2 Required Reputation:2, but User1 still can build or destroy. I stop the server and check in the user.yml permissions file for the world I am in and don't see greylistvote.approved on User1.
I check the users.yml in the GreylistVote folder and see that User1 shows:
votes: null,MyUserName
Sooo...is something go wrong here, or do I have a misconfiguration?
UPDATE:
Okay, I issued greylist User1 from the console and got a message to go forth and buildify! When I looked in the greylistvote/users.yml, I now see User1 with votes: Server.
I stop the server and examine the permissions files. I still don't see greylistvote.approved anywhere (groups or users). I start the server and User1 get the "cannot build message" again. When I check with votelist, it shows the reputation level as 1 and needed as 2, although the Server was the one that approved this user. But this time, when my player types /greylist User1, User1 gets the "go forth and buildify" message as expected.
Based on this, I am guessing that the "null" that was in the users.yml file to begin with was causing problems?
But still, when I stop the server, I don't see any permissions written for the user, and when I start it again, the user again cannot build. votelist User1 does show reputation 2, needed 2.
I am using bPermissions...not sure if it is breaking the rules for permissions or not.
Version 1.1 is now uploaded. it contains MAJOR changes, so please re-read the whole of the overview to make sure you are up to date.
The new version adds new commands, new permissions and changes how votes are treated.
@gyroninja
Yes that does make some sense. Look out for this in the next update
@TeamAss
Currently the system doesn't ban the griefer, it just removes their build rights, which can be reinstated on receipt of new votes. I am considering adding custom commands, as was recommended by techdesign, but it will take me a while to add this. I'll add it to the future plans.
Could you make it so that when you type /griefer <name> It executre's a configurable command defined in the config, rather than just a ban? Like we can use it to execute a jail command, to jail the player etc?
You should have when the console votes, it will take 1 console vote to accept or deny. I dont know of many minecraft servers where you can just get access to the console without owning it.
@techdesign
OK... I found the big bug with assigning the .approved permission. I've now upgraded the latest release to version 1.0 (Full Release)
Feel free to give it a try out and let me know how you get on!
@techdesign
Which bit didn't work? Did it fail to stop building or did it fail to promote on receiving bids?
It was built to work with Bukkit's built in permissions, but should work with other permission systems providing they are compatible with the latest version of Bukkit. However, I am aware of a bug affecting the approval process. I though I had fixed it on the 0.3.3 build but evidently it is still lurking around. I'll take another look.
Regarding custom commands, I would love to add this kind of functionality to the plugin. The execution might be tricky given the way the current system works, but it's certainly something I'll look into.
By the way, I tried this with bPermissions and it failed. I'm not sure if it supposed to work or not. I assume it attempts to use the default bukkit permission API to add a permission to an individual user? I'd be happy to test it out if you want me to try something different.
Very nice. I just commented in the MajorityVote thread where I saw you had commented as well. I assume GreyListVote came about as a desire for what MajorityVote could not do.
So along the lines of what you have mentioned below, and what MajorityVote did allow, I'd really like to see the ability to have custom console commands executed based on a vote. At that point, you wouldn't need to worry too much about supporting each permission system if they each could be controlled via the console.
With bPermissions for instance, I could execute the "promote" command, or another command to change groups for a user. It would be nice to have the ability for different variables though. Perhaps %arg1% %arg2% etc. Maybe %world% for the world where the vote was initiated?
Tested against CraftBukkit 1717 for 1.1 compatibility
@harshmm123
At the moment this plugin sticks to the native permissions for Bukkit (SuperPerms / Permissions Bukkit). Although it will work with the other permission systems adding group support may exclude some servers.
With that said, I may well look at adding that kind of capability, perhaps by allowing configurable commands to be run on receiving enough votes...
For example: If using GroupManager you could set up command: manpromote {player} GroupX votes-required: 3
Is that the kind of thing you had in mind?
You should add this for certain permission groups too :) Ex: People can vote for someone to get one rank higher on the permissions ladder; what would be even more awesome is if you did it for PEX and hopefully added the ability to have only certain groups able to vote, or maybe so you can have a list/config of which groups are achievable by voting :D
@ellbristow
Superb! :D
I'll drop it in my server first thing tomorrow morning and let you know how it goes.
Nice work squire. ;)
@MuttzNutz
I surpass even my own expectations!
0.3 beta is up and /griefer is in, but it's not fully tested. Let me know how you get on with it.
@MuttzNutz
I like the ungreylist idea. I would probably call it /griefer but essentially it's the same idea. I think this would also need the ability to remove the griefer vote in case someone changes their mind.
Expect to see this in the next release (which at the rate I'm going could well be tomorrow!)
Not sure about the /tbgreylist idea. I see how it would be advantageous... I'll have to give it some thought.
Thanks for he feedback. Keep it coming.