Grief Prevention
AUTOMATICALLY PREVENTS ALL FORMS OF GRIEF, including build/break, theft, spam, fire, spawn camping, lava dumping, chat trolling, advertising and more, so you don't have to undo any damage after the fact. It even teaches players how to use it so you don't have to! No configuration or database required. Stop responding to grief and prevent it instead. Grief Prevention will solve your grief problems without requiring you to manage a roster of trained administrators, juggle 10 different anti-grief plugins, take away cool standard game features, publish a training manual / tutorial for players, or add explanatory signs to your world. You can also choose to integrate PvP elements into build design to finally get a PvP experience befitting a sandbox game about creative building.
Grief Prevention stops grief before it starts automatically without any effort from administrators, and with very little (self service) effort from players. Solve all your grief problems with a single download, no database, and no configuration step.
Got a question or found some random bug? Check the documentation!
Got a problem or bug you can reliably reproduce? Or a feature request? Report it on the issue tracker!
Also, you might be able to catch me/others on the #GriefPrevention IRC channel for help (please state your question and exercise patience if you use this option).
Downloads for older Minecraft Versions
You may also view recent update notes on Github
The Manual
Feature List
Yes, everything is customizable.
- No database or world backups required.
- Extremely efficient CPU / RAM usage.
- Land claims are easy to manage.
- Players create and manage their own land claims, so you don't have to do it for them.
- New players get automatic claims around their first chests so they're protected even if they don't know how to create land claims yet.
- Players who ask for help in chat get an instant link to a demonstration video.
- Resizing claims and creating new claims is done with ONLY the mouse, no slash commands (slash commands are also available).
- When a player appears to be building something nice outside his claim, he's warned and shown his claim boundaries.
- Claim boundaries are easy to see, and don't require any client-side mod installation.
- Extremely easy-to-remember, single-parameter slash commands for giving other players permissions.
- Claim subdivision and granular permissions are available to organize towns and cities. Watch this video.
- It's IMPOSSIBLE to grief a land claim. Watch this video.
- No building or breaking.
- No stealing from ANY containers.
- No sleeping in beds.
- No button/lever usage.
- No adjusting redstone repeaters or other configurable blocks.
- No pushing blocks in with pistons.
- No pulling blocks out with pistons.
- No TNT damage (including cannons).
- No creeper damage.
- No explosive damage from other plugins, like Extra Hard Mode or Magic Spells.
- No enderman/silverfish block changes.
- All doors may be automatically locked (optional, see config file).
- No killing or luring animals away.
- No stealing water (e.g. buckets).
- No trampling crops by players, animals, or monsters.
- No building overtop, all claims reach to the max build height.
- No placing or breaking paintings / item frames / armor stands, etc.
- Fluids will not flow into a claim from outside.
- No placing blocks via TNT/Sand/Gravel cannon.
- Pets and death loot are protected.
- Players can't pick up what another player dropped on death without permission.
- All types of pets are protected everywhere, even outside of land claims (can be configured per-world).
- Excellent anti-spam protection
- Warns, then mutes, then may kick or ban spammers (configurable - you choose).
- Most spammers get only one message out before they're muted.
- Blocks server advertising (IP addresses).
- Blocks repeat message spam.
- Blocks ASCII art (ex. Nyan Cats) spam.
- Blocks similar message spam.
- Blocks unreadable (gibberish) message spam.
- Blocks CAPS.
- Blocks macro spam (very different messages in quick succession).
- Blocks login/logout spam, even when the spammer has multiple accounts.
- Blocks death spam.
- Blocks bot team spam.
- Blocks slash command spam, including /tell, /emote, and any more you add.
- Wilderness Protection and Rollback
- Fire doesn't spread or destroy blocks.
- Creepers and other explosions don't destroy blocks above sea level.
- TNT doesn't destroy blocks above sea level.
- No planting trees on platforms in the sky ("tree grief").
- Instant, point and click nature restoration for not-claimed areas. Watch this video.
- Insanely easy and fast fixes for penises, swastikas, and anything else unsightly.
- Point at what you don't like and click, and it's fixed. Even from far away.
- Never accidentally changes blocks inside land claims.
- No need to investigate who built it, who broke it, or when they did it.
- Doesn't matter if the griefer built with "natural" blocks, it will still be fixed.
- No database.
- No backups.
- No chunk regeneration (it's dangerous for technical reasons).
- Fixes bad chunk generations, like floating islands. It will be better than new.
- Fills holes, even next to water to correct big spills.
- Smooths noisy terrain.
- No griefer construction is safe. If it's unnatural enough to be noticeable by players, it will be removed or filled-in.
- Land claims can't be used as a griefing tool.
- It's impossible to get a player "stuck" inside a land claim.
- Land claims beyond the first require a golden shovel.
- Minimum claim size prevents sprinkling small claims to annoy other players.
- Max claim allowance grows with time played on the server, and can't be cheated by idling.
- A simple administrative slash command will instantly remove all of a griefer's claims, no matter where they are.
- Catches clever griefers.
- Enhances the /ban command to ban ALL a griefer's accounts (not just his IP address).
- Logs sign placements.
- /SoftMute command to shut down chat trolls without them knowing they're beaten.
- Abridged chat logs make reviewing what happened while you were away super-quick and easy.
- Automatically mutes new-to-server players who use racial or homophobic slurs.
- PvP Protections.
- When PvP is off, no setting fire or dumping lava near other players.
- Absolutely bullet-proof anti-spawn-camping protection including bed respawns, which requires no configuration.
- No logging out, stashing items, or using plugin teleportation to escape combat.
- Optional siege mode, to answer players who hide in their claimed houses to avoid combat.
- Supports your server growth.
- Permit players to exchange server currency for claim blocks (requires configuration and other plugins).
- Grant claim blocks automatically for votes, donations, etc (console command provided, other plugins required).
Please Vote for Grief Prevention
I've also posted Grief Prevention on the Spigot site, where plugins are ranked based on reviews. If you love GP, please take a couple of minutes to give GP your rating and leave a short review. Better rating and positive reviews will help server owners who look for plugins on the Spigot site make the safe choice (GP) instead of downloading something sketchy or incomplete. :) Thanks so much for all your support!
http://www.spigotmc.org/resources/griefprevention.1884/
Got a question or found some random bug? Check the documentation!
Got a problem or bug you can reliably reproduce? Or a feature request? Report it on the issue tracker!
Also, you might be able to catch me/others on the #GriefPrevention IRC chat channel for help (please state your question and exercise patience if you use this option).
-
View User Profile
-
Send Message
Posted Feb 24, 2012@CrystalPriizon
lol wow that sounds super weird. Please try to eliminate other plugins as the problem. I don't have any special code around nether portals at all.
-
View User Profile
-
Send Message
Posted Feb 24, 2012@bigscary
Thanks! *resumes mashing F5*
-
View User Profile
-
Send Message
Posted Feb 24, 2012I don't know if it's this plugin, but it seems more likely than any other I have. In the nether, we can build right around the portal, but if we walk about 15 blocks away we can't, and when we get about 40 blocks away we can again. What's up with that small distance that we can't build? We can still break blocks.
-
View User Profile
-
Send Message
Posted Feb 24, 2012@cvxx7q
About the enderman, I don't think we have that issue. If you see that we do, please tell me how to reproduce the problem so that I can fix it.
If you want to give stuff away to others, just put a box outside your claim. I assure you, people will "steal" from it, no custom code necessary.
Files only get an update when claims change and when players log in/out. Both happy relatively infrequently (versus breaking blocks, killing monsters, and so on). Files are only read once, then their data is stored in memory, so that's not an issue. As for the rest of performance, it's been tuned to a reasonable extent (some basic caching). If performance one day becomes an issue, I'll look into taking more steps.
@Jadedwolfs
I will fix that today. I think you might have overreacted a little there with that alarmingly large text. :)
@briankdk
Ordinary players don't need permissions. Ops have all the permissions they need. As for moderators, sorry, you have to read the manual to decide for yourself what permissions you will give each individual, based on how much you trust him/her.
Thanks everyone for your detailed reports, it's nice to have some actionable information (I often don't get enough details to reproduce a problem). I'll look into the mentioned issues.
Spblat, I think from your latest message there that I have it figured out in my head. So there should be a fix very soon, probably today. I think it's related to the recent caching improvements.
Regarding permissions with spam, I'm at a loss. Please try another permissions plugin to see if the problem is remedied. Because you can't reproduce the problem with vanilla permissions (op), I can't imagine how the problem could be with my code. I'll double check that I'm checking the right permission node in code.
By the way, once I'm feature complete (minus pvp), I will be releasing the source. Every time I get ready to release it, a new feature pops up that I feel is a must-have, like the /trapped command.
@saintcrime
No, you can't disable new player automatic claims on a per world basis. You can only turn claims off entirely per world, or new player claims off entirely for all worlds. Will you please post again to describe your scenario, so that I can understand why you would want this? It seems like a real corner case to me.
-
View User Profile
-
Send Message
Posted Feb 24, 2012@saintcrime
Thanks for your reply. My experience differs from yours in two respects:
-
View User Profile
-
Send Message
Posted Feb 24, 2012@spblat
I checked out the problem you had and I was able to reproduce it like you said. I then did some checking and figured out what causes it and why/how to fix.
If your GriefPreventionData\config.yml has the following line set to "true"
CreationRequiresPermission: true
And you have not given the person who is trusted in the subdivision this permission
griefprevention.createclaims
You will get the "Bug" where they can start to build then leave the subdivision, build outside, return to subdivision and cannot build anymore in the subdivision.
I was able to have this not happen by changing CreationRequiresPermission: true to "false" or leaving this setting alone and give the person with the trust on the subdivision the griefprevention.createclaims: true permission in my permissions plugin config.yml.
I hope this helps you :)
-
View User Profile
-
Send Message
Posted Feb 24, 2012Is there a way to prevent automaticnewplayerclaims on specific worlds or for specific groups, but not restrict everyone with the Griefprevention: Claims: AutomaticNewPlayerClaimsRadius: -1 in the Griefprevention Config. I need people to not be able to make newplayer claims with chests on certain worlds, or possibly for certain groups. Is there a permission or something separate from the Grief Prevention Config?
-
View User Profile
-
Send Message
Posted Feb 23, 2012I think I have my bug figured out and reproducible.
I've confirmed this with a virgin server on default settings, using only R4 and the latest GP and Vault.
-
View User Profile
-
Send Message
Posted Feb 23, 2012I was using it, seemed to work fine. Just me and my few friends testing it, I had 600 claim blocks, I had them check and they each had about 80000 blocks... what?
-
View User Profile
-
Send Message
Posted Feb 23, 2012Hello bigscary,
problem ticket:
setting griefprevention.spam: true to a non op does not let them bypass the login check.
User has to be in ops.txt file.
Steps to reproduce:
prep before each time the steps below were performed:
Fresh craftbukkit R1.1-R4.
Fresh install permissionsBukkit 1.2 + superperms bridge.
added myself to whitelist.txt
in permissionsbukkit/config.yml: added myself under users, as follows:
users.cdrgnfly.permissions.griefprevention.spam: true
Fresh install (no griefpreventiondata folder) of griefprotection.jar (checked with v1.8.1 and 1.8) in plugins folder.
Using either an unmodded normal minecraft 1.1 client or spoutcraft 1.1RB client:
Step 1. log in. Get a nice little I'm pvp safe msg. :)
Step 2. disconnect.
Step 3. Connect again.
Expected outcome: I get in.
Actual outcome: I get a message saying I need to wait 4+ minutes to log in.
Variation:
Add to permissions.yml:
server.gp:
children:
griefprevention.spam: true
Then add server.gp to config.yml in permissionsbukkit for that user (tried groups too).
stop server. Delete griefpreventiondata folder.
Repeat steps 1-3.
Still get actual, not expected.
Current workarounds:
1. add myself to ops.txt.
Restart server (regardless of deleting the gpdata folder or not).
bingo, I score access. get expected result every time.
2. set GriefPrevention.Spam.Enabled to false.
3. set GriefPrevention.Spam.LoginCooldownMinutes to 0.
Can't check source - don't see a link in 'repository' or a way to help fix the problem.
Can't file ticket, no tickets page for this project.
(please forgive shortening griefprevention to gp. that's a heck of a word to type).
Also tried: gp.ignoreclaims: true to see if that was the one. Nope.
tried: gp.admin.*: true to see if that worked perhaps. Nope.
Also, checked to ensure perm was true ingame using cmd:
/perms check griefprevention.spam (after added proper perms to allow use of this cmd).
Problem summary: griefprevention.spam: true does not work as advertised for
login cooldowns.
Thanks very much for this plugin.
Peace.
cdrgnfly
-
View User Profile
-
Send Message
Posted Feb 23, 2012I was having the same problem as briankdk. Sometimes one of three bukkit commands helped:
1) p reload (using bPermissions) 2) reload 3) restart server
But even when this did help and my player started building in my subdivision, they were soon once again unable to do so.
I can tentatively say this problem is fixed in 1.8.1, but it may be too soon to be sure. My other plugins are listed here: https://sites.google.com/site/spblatmc/home/plugins
-
View User Profile
-
Send Message
Posted Feb 23, 2012strange... i have followed your video about subdivideclaims exactly..... the townzone gets gold colour - subdivideclaims are silvercolour.
If i do /trust olivermcdk (while standing in the subzone - then olivermcdk still cant build in that zone - he just gets the message "you dont have briankdk's permission to build here."
If you want to check plugins etc - the server is running on 80.72.154.63 - when joining just type /warp new_town - and you will arrive at the place that im using to test your plugin.
I have given you VIP/Developer status - so that you have ' * ' (all right to everytning)
If you want to se the plugins there is on my server just type /pl
Hope you can figure out why it isent working - i really want to use your plugin....
These are my plugins: Plugins: UltimateArena, SafeEdit, WorldEdit, iZone, Vault, PermissionsEx, WorldGuard, Marquee, LazyRoad, BorderGuard, MineBackup, SimpleJail, Spectate, iConomy, Permissions, pvparena, Lockette, Modifyworld, GriefPrevention, AdvLog, Essentials, Jobs, ChatManager, EssentialsSpawn, CreativeGates, LogBlock, LWC, ChestShop A few of the plugins arent "really" there, but just "there" because others request their presence.
-
View User Profile
-
Send Message
Posted Feb 23, 2012looks pretty nice ;3 plan on using it for my server for protectign players who build diffrent things out of range of a town
-
View User Profile
-
Send Message
Posted Feb 23, 2012Hi
Im using PEX (permissionX),
what permissions should i give ordinary users ? so they can protect their own lands, etc
What permissions to give Moderators
What permission to give Admins
What permissions to give Owners (they allready have '*', so imguessing the have it all)
I have read the bottom here: http://dev.bukkit.org/server-mods/grief-prevention/pages/administrative-details/
But im not getting it - sorry - but in not native english...... so was hopig you could make it more easy for me to understand what permissions to giuve to each group of users......
-
View User Profile
-
Send Message
Posted Feb 23, 2012@bigscary
Huge huge issues with 1.8.1
Creepers now can explode logs even if you have creeper explosions blocked... So I have creeper explosions blocked via WG and now they can blow up logs, only tree logs, but that's enough that i had to revert to an older version of this plugin.
-.-
-
View User Profile
-
Send Message
Posted Feb 22, 2012@bigscary
well ive always liked the donation chest,
also to exapnd, how about chests for crap i dont want? so if i dont want that 3 stacks of sandstone (example) i cud just chuck it in a chest on my lawn :P
and i suppose it could be a lucky draw thing, punch it and see what u get, i guess u cud let ppl punch it as much as they like or limit it somehow, id rather let em punch for awhile lol
EDIT: also as for the enderman one trick i saw in the first anti enderman plugin was to let the enderman duplicate blocks, so when he goes to steal your precious cobblestone wall, the block will stay and he will still get a cobble, imagine how lucky you'd be if he grabbed a diamond block off your lawn :P!
@bigscary
yeah no SQL sorry guys but it really does make u wanna kill urself with ur mouse cable (what a weird image in your brain right now lol)
i dont doubt or think your plugin performance lacks at all but i was saying if all the claims were being written and read form the drive all the time it would come down to the OS and Disk Drives Scheduling, which IMO is far far better than ever, and SQL would only be needed if u chose to use a single Text/YAML file which would require reparsing everytime a claim changed (and of course your not so stupid to do that :P)
@bigscary
when u punch out a fire u generally hit the block below it is that in anyway useful for your your issue? when i was testing your early builds (back when the claim format was messed up) i couldn't destroy protected fires
-
View User Profile
-
Send Message
Posted Feb 22, 2012There's been a cool idea submitted by TaterTotsYum, and I like it. Please tell me if you have any objections to its addition.
Players may place items in other players' chests, even when they don't have any permission in the claimed area where the chest rests. This would allow players to "donate" items to others while those other players are offline, without giving those other players access to remove items from chests, or even view the contents of the chests.
This would work with any chest, and a player would hold the item to donate and "punch" the chest to donate. The player would get a warning message on the first punch, to avoid "oops, I gave away my diamond" situations.
A griefer could maybe fill the open spaces in a chest with some crap item like dirt, but that's a very small problem, I think (it's still free blocks, and they can be collected very quickly by breaking and replacing the chest). Players who are organizationally obsessed could simply add an iron door to their chest room, and leave one chest out for strangers to donate if they like, or grant /accesstrust to only the players who they trust to donate.
-
View User Profile
-
Send Message
Posted Feb 22, 2012@leezallen
I don't plan to add groups support. If you want to change the owner of a claim, there's no easy way to do it via direct file editing, sorry. Best approach is to have an admin use /deleteclaim to remove the original claim, then have the new owner claim the land.
-
View User Profile
-
Send Message
Posted Feb 22, 2012@zathrus_writer
That chest gadget was a hypothetical example of something admins might want to protect with adminclaims. Making the infinite chest function would have to involve another plugin.
@rebel24
I haven't seen that problem before. Do you know which player caused it and what he was doing? Can you find any way to make it happen consistently, so that I can reproduce the problem and investigate?
-
View User Profile
-
Send Message
Posted Feb 22, 2012@majoraw
Okay I'm not sure exactly what you mean by multiworld claim blocks, BUT currently, players can use their claim blocks in any world where you enable claims. Administrators can create admin claims in all worlds, regardless of your settings.
Not going to add MySQL support. It won't add a lot of value, will complicate the code, and will give administrators just enough rope to hang themselves with (when they need to do maintenance later).
@cvxx7q
I guess there are some questions about performance? Currently, everything about claims is held in memory, so the hard drive doesn't become a bottleneck. Keeping claims and player data in separate files on the hard drive makes viewing, changing, backing up, and migrating the data easy and familiar (it doesn't involve any database knowledge).
@Tux2
I'm aware of the netherrack problem. I haven't found a solution, although I have looked for one. Apparently, placing fire is a "block place" event, but putting it out is NOT a "block break" event. So I dunno.
@mrgreaper
I don't know. Generally, grief prevention treats all blocks the same, so as long as your plugin isn't doing something incredibly odd, it should work. Just try it out. Regarding blocking block changes in claims, that depends on whether the plugin you're asking about correctly identifies the player making the change. If it does, then there should be no problem with grief prevention.