[INACTIVE][SEC] AntiGrief v1.2.1 - Anti-Build+Anti-Grief Measures with Polygon Zone Protection [818]

AntiGrief v1.2.1 [Download]
AntiGrief is a Prevention plugin with multiple aims:

• Prevent potential griefers.
• Control who can do what.
• Give the server owner complete customization.
• Define limitations based on in game created zones.

What this means is you have complete control over who can do what on your server.

• You can allow guests to visit your server without being able to do anything.
• You can prevent certain actions from being used by anyone or certain groups.
  • This can be done by action, or even by item.
• It is up to you as the server owner, you can customize every element.

Features:

• Prevent/allow any action.
  • Prevent/allow any action with specific item customization.
• Prevent the use of TNT/Explosions/Fire/Lava/Water.
• Prevent Mob Targeting (I.e. Prevent griefing via lured creepers).
• Prevent players from damaging other players.
• Prevent players from receiving damage in multiple ways.
• Prevention of the usage of vehicles.
• Prevent on a per-world basis.
• Prevent via user defined polygon zones.

Version 1.2.1:

• Compiled with 818

Version 1.3 [coming soon]:

• Zones now have enter and exit messages
• New zone commands to add enter and exit message and command to delete zones
• Ability to prevent explosions in a zone
• Ability to prevent creature (by type) from spawning in a zone
• Fixes to zone creation and visualization (unable to break visualizing blocks)
• Users can only modify the zones they created
• Ability to modify the area of a zone
• Can modify points while creating a zone
• Ability to set default actions allowed inside a zone
• Slight modification to the main configuration file (prevent_nodes is nodes.prevent again and allow_nodes is nodes.allow again) - this way nodes.prevent/allow follows the same logic as prevent/allow when preventing/allowing an item based on a certain action
• The ability to disable an item completely outright or by group/user
• Other fixes/enhancements

Version 1.0.3:

• Fixed a logic error dealing with preventing items (<node>.prevent)

Version 1.0.2:

• Many bug fixes.
• Fixed zones - they now work properly and match main configuration format.
• Changed some nodes around
• Some changes to config format.
• Prevent item use added back
• Fix for door interactions

If upgrading to 1.0.2+ it is recommended that you let AG re-create your configuration files. I know it is a pain, but the new changes/increase customization required some shuffling/creation of settings that need a new format (mostly re-naming).

AG requires GroupManager or Permissions although GroupManager is recommended for use with AG!

Links:
Wiki
Download
Report Issues
Changelog

 

Try this config:

Code:

plugin:
  permissions: {system: default}
groups:
  Default:
    default: true
    info: {prefix: '', suffix: '', build: false}
    inheritance: []
    permissions: ['general.spawn']
  Moderator:
    default: false
    info: {prefix: '', suffix: '', build: false}
    inheritance: [Default]
    permissions: ['general.time', 'general.teleport', 'general.teleport.here', 'general.player-info']
  Admins:
    default: false
    info: {prefix: '', suffix: '', build: false}
    inheritance: []
    permissions: ['*']
users:
  darkgrave:
    group: Admins
    permissions: []
  sk89q:
    permissions: ['general.time']
    group: Default

I just modified yours into a different format. Second, your users are the default users that come with permissions. You need to modify those on individualized people in your server. Otherwise the default group will always take over.

Using this permission file, as a default user, it works right for me.

 

I have tested the creeper portion of this mod and can say that it works with your suggested fix. However, when I moved my test subjects back into their normal groups (groups that are not set to ignore creepers), they players seem to maintain their immunity to creepers.

This is a pretty big problem for me because my intention was to have visiting players to my server not stir the creepers, and any players who get promoted to be able to build should attract the creepers. As it stands, my testers are stuck with the creeper immunity unless I completely remove the mod and put it back in! Thank you for all your help!

 

Did you do a hard /reload afterwards? I am able to move between groups, I just have to use /reload. Using /pr or essentials group modifying function does not seem to properly reload permissions. Chat and stuff changes right, but the checks I do to see what groups users are in still report the old values.
As of now the only work around is /reload as far as I am aware. But I will see if there is anything more I can do.

 

Oh new version is out

ignore: in the config still works?

So I have to use this:
ignore:
- 'antigrief.block.interact'
- 'antigrief.vehicle.use'
- 'antigrief.vehicle.move'
- 'antrigrief.player.use'

Or now?
ignore:
- 'antigrief.allow.block.interact'
- 'antigrief.allow.vehicle.use'
- 'antigrief.allow.vehicle.move'
- 'antrigrief.allow.player.use'

Or I have to insert this (which?) now to the permissions?

And, If I add - 'antigrief.prevent.entity.entity_attack' to the permissions or your config,
my default suers can't do pvp damage, but others can do damage to them? (This is what I want)
And what's damage.contact?

Thanks

 

Ignore is gone.
Let it create a new config, instead of ignore it now has the affects variable which are all the actions that AntiGrief will do. You remove from that to change what build: false will do (I figured it would make more sense this way).
For the affects part you only need to use the node names, so block.interact, vehicle.use, etc. These are what build: false will do on a user.

In the permissions you add the antigrief.allow/prevent permissions which act as additions based on what build: true/false you have set.
So build: false means all the affects variables from the config will effect that user. (So if I add antigrief.allow.block.interact, this user will be able to interact with blocks even though build: false would normally prevent it.)

('antigrief.prevent.entity.entity_attack' would be added to the permissions, unless you want build: false to mean that entity_attack does not affect build: false users then add 'entity.entity_attack' to the affects of the config)

As for entity.* stuff I am not sure what they all do, they are hooks into the possible damages that can be done. As of now they will only affect the damage a user can receive. I will add hooks so you can prevent the user from attacking as well.

 

No one has a solution yet? Here is my permissions config:

Code:

plugin:
  permissions: {system: default}
groups:
  Default:
    default: true
    info: {prefix: '', suffix: '', build: false}
    inheritance: []
    permissions: [essentials.spawn]
  Builder:
    default: false
    info: {prefix: '&1', suffix: '', build: true}
    inheritance: []
    permissions: [essentials.portal, essentials.world, essentials.msg, essentials.afk,
      essentials.rules, essentials.motd, essentials.list, essentials.mail.send, essentials.me,
      essentials.helpop, essentials.whois, essentials.help, essentials.home, essentials.sethome,
      essentials.warp, lwc.protect]
  VIP:
    default: false
    info: {prefix: '&6', suffix: '', build: true}
    inheritance: [Builder]
    permissions: [essentials.tp, essentials.tpa, essentials.tpaccept, essentials.tpdeny,
      essentials.tphere, essentials.tpahere]
  Moderator:
    default: false
    info: {prefix: '&a', suffix: '', build: true}
    inheritance: [VIP]
    permissions: [essentials.top, essentials.jump, essentials.modgrp, essentials.kill,
      essentials.broadcast, essentials.item, essentials.give, essentials.heal, essentials.ban,
      essentials.banip, essentials.kick, essentials.unban, essentials.unbanip, lwc.mod]
  SuperMod:
    default: false
    info: {prefix: '&a', suffix: '', build: true}
    inheritance: [Moderator]
    permissions: [essentials.spawnmob, essentials.setwarp, essentials.delwarp, essentials.tree,
      essentials.bigtree, essentials.setspawn]
  Admin:
    default: false
    info: {prefix: '&4', suffix: '', build: true}
    inheritance: [SuperMod]
    permissions: ['*']
  Founder:
    default: false
    info: {prefix: '&e', suffix: '', build: true}
    inheritance: [Admin]
    permissions: ['*']

 

Are you using v0.5? They still can't build?

 

Is there no node for disabling tnt on group/user basis?

 

Yeah, I am. And sometimes it works, but new people wont

 

Reloading the server seems to have the same effect: my friends are being ignored by the creepers as far as I can tell.

 

hm. Using default settings, if I start with build: false and stand next to a creeper I will be ignored. If I then set the group im in to build: true and do /pr /reload the creeper will turn around and blow up next to me.

With the logging update I am working on I will add toggle-able information for troubleshooting.

 

still doesnt work for me. newest version, my old friend who I made VIP cant do squat.

 

Creepers can only see him if I remove antigrief.prevent.entity.creeper from the "Visitor" group, even though he is "VIP" group. It thinks he is in the Visitor group no matter what I try now.

 

does VIP inherit from Visitor?

i.e. here is my antigrief config:

Code:

affects: ['block.damage',
'block.place',
'block.interact',
'block.ignite',
'entity.creeper',
'player.item',
'vehicle.use',
'vehicle.move']
level: ['lowest']
canInteract: ['64']

This means that anyone with build: false cannot do the following with blocks: place, interact, damage, ignite. Creepers will not notice them, players cannot use items, and vehicles cannot be used/moved. (However players can interact with doors.)

Code:

plugin:
  permissions: {system: default}
groups:
  Default:
    default: true
    info: {prefix: '', suffix: '', build: false}
    inheritance: []
    permissions: ['antigrief.prevent.entity.creeper']
  Moderator:
    default: false
    info: {prefix: '', suffix: '', build: true}
    inheritance: [Default]
    permissions: []
  Admins:
    default: false
    info: {prefix: '', suffix: '', build: true}
    inheritance: [Moderator]
    permissions: ['*']
users:
  crowebird:
    group: Admins
    permissions: []

With this, Antigrief will have no affect on Admins or Moderators. But Admins do inherit from Moderators who inherit from Default. If I add antigrief.prevent.entity.creeper to the default group, it is only enhancing the antigrief config which already blocks creepers for build: false. BUT moderator is inheriting that, so they are also cancelling the creeper even though build: true. The admin won't be affected because with the * permission they are utilizing the antigrief.admin permission which means AntiGrief will have no affect on them whatsoever.

Hope that sums up some things and helps to fix any problems you guys may be having. Otherwise I am unable to reproduce.

So I believe it is the inheritance issue causing problems. I do see an issue though on my side that won't allow you to add antigrief.allow.entity.creeper to the VIP group, because build is already true and my code won't check that you have that permission to cancel that affects of an antigrief.prevent.entity.creeper also.

 

can this also rollback players or give me logs on who broke a block?kinda like big brother i really need that

 

Right clicking switches still triggers them no matter what you set any of the options to.

Left clicking a switch never works unless players are also allowed to place/destory blocks.

Something like, right clicking doesn't work (unless left clicking also does), and left clicking does work when you want it to (without people being able to build as well) would be great. I have a lot of "doors" that use buttons to open, and I don't specifically want everyone to be able to operate them, but some users I do.

Any chance of looking into this?

Cheers in advance!

~Sol
--- merged: Feb 21, 2011 5:02 PM ---

No, it has no rollback or logging features, unfortunately.

~Sol

 

Regarding rollback. Not really planning on implementing rollbacks. This is meant to prevent actions in the first place so a rollback would be unnecessary.
I am however implementing logging, which I will leave open to any type of action that you as the server owner specify (Any action taken on certain blocks regardless of build state - up to you).

@Sol regarding right and left clicking. Left clicking technically starts the destroy action on a block, but if that block is usable like a door it also triggers it. I missed checking on both sides of the hooks (I really only implemented the door left click check with allowInteract).

As far as triggers go, I never tested that far. With the default settings I prevented triggers (left and right click) and left it as that but never checked other cases. I will implement a fix with the next update.
===
Expect a few days for update though, I have a lot of other work going on and will probably wait until the next version of permissions and a newer version of CB is released, since it seems like some changes to the plugin will need to be made anyway around that time.

 

Cool mate no worries. Just making you aware, just in case you weren't.

I have managed to make due for now... it just means my noob traps and "IQ TEST" won't work as intended, but I can live with that for now Most people don't think to right click anyway... so for the most part it works fine.

~Sol

 

Fixing my permissions seems to have fixed my problems. Didn't think about that! Thanks for the help. Seems to be working great after /reloadall.

 

OK so...

I am running OnlineMode=True, AntiGrief, Guestbook, AND Permissions... yet somehow in the last two days I have been griefed like 3 times MAJORLY. It is ALWAYS with a flint and steel. Somehow, someone is logging in and somehow getting a flint and steel and buring down shit. I checked server logs, there is no "whitelisted" players on so it's not a resident/regular member. IP addresses do not match up etc.

Has anyone got any idea how this could happen? Is there some new magical inventory hack that works with a (supposed) server-side inventory? How are these assholes able to bypass THREE anti-griefing measures?

~Sol
--- merged: Feb 22, 2011 3:08 PM ---
Nevermind... it was one of the "residents". Give them an inch, and see what happens.

~Sol

 

Hey there. CB 443, Minecraft 1.3, Permissions 2.1:

Code:

2011-02-22 23:56:57 [SEVERE] Could not pass event BLOCK_DAMAGED to AntiGrief
java.lang.NullPointerException
        at com.crowebird.bukkit.AntiGrief.AntiGrief.canBuild(AntiGrief.java:129)
        at com.crowebird.bukkit.AntiGrief.AntiGriefBlockListener.onBlockDamage(AntiGriefBlockListener.java:24)
        at org.bukkit.plugin.java.JavaPluginLoader$23.execute(JavaPluginLoader.java:242)
        at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:59)
        at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:225)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:340)
        at net.minecraft.server.Packet14BlockDig.a(SourceFile:42)
        at net.minecraft.server.NetworkManager.a(SourceFile:230)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:70)
        at net.minecraft.server.NetworkListenThread.a(SourceFile:100)
        at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:338)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:252)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:366)

 

CB 443 eh. Is that like...a build from the future?

 

@Egg, I have tested this against 424 with no issues (at least I don't think there was issues )
Although I have not upgraded the plugin to support Permissions 2.1 yet.

Also your particular error usually pops up when the permissions file is incorrect (I usually get that error when I spell the group name wrong for a user.)

 

Got this on caraftbukkit 432

Code:

2011-02-23 15:08:35 [SEVERE] Could not pass event ENTITY_DAMAGED to AntiGrief
java.lang.NullPointerException
        at com.crowebird.bukkit.AntiGrief.AntiGrief.canBuild(AntiGrief.java:129)
        at com.crowebird.bukkit.AntiGrief.AntiGriefEntityListener.onEntityDamage(AntiGriefEntityListener.java:32)
        at org.bukkit.plugin.java.JavaPluginLoader$39.execute(JavaPluginLoader.java:329)
        at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:59)
        at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:225)
        at net.minecraft.server.EntityLiving.a(EntityLiving.java:487)
        at net.minecraft.server.Entity.a(Entity.java:581)
        at net.minecraft.server.EntityPlayer.b(EntityPlayer.java:253)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:248)
        at net.minecraft.server.Packet10Flying.a(SourceFile:126)
        at net.minecraft.server.NetworkManager.a(SourceFile:230)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:70)
        at net.minecraft.server.NetworkListenThread.a(SourceFile:100)
        at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:338)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:253)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:366)
2011-02-23 15:08:46 [SEVERE] Could not pass event BLOCK_DAMAGED to AntiGrief
java.lang.NullPointerException
        at com.crowebird.bukkit.AntiGrief.AntiGrief.canBuild(AntiGrief.java:129)
        at com.crowebird.bukkit.AntiGrief.AntiGriefBlockListener.onBlockDamage(AntiGriefBlockListener.java:24)
        at org.bukkit.plugin.java.JavaPluginLoader$23.execute(JavaPluginLoader.java:242)
        at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:59)
        at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:225)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:357)
        at net.minecraft.server.Packet14BlockDig.a(SourceFile:42)
        at net.minecraft.server.NetworkManager.a(SourceFile:230)
        at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:70)
        at net.minecraft.server.NetworkListenThread.a(SourceFile:100)
        at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:338)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:253)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:366)

I use groupmanager ( works with the same as permissions 2.0)

 

many thanks!

 

Err, yeah, sorry typo there. I meant 423. This also occurs with 432 and Permissions 2.1.

My permissions file is the same used under 2.0 and hasn't changed. I rolled back to 2.0 and do not get the NPE with the same permissions file. I can't say if the issue is with Permissions or AntiGrief, but wanted to report it.

 

So I am trying to create a new build but am having issues with permissions 2.1.
The errors are being thrown when I call a Permission function, so not sure exactly what is going on.

Note that AntiGrief will not work with 2.1 as 2.1 checks for individual world permissions and AntiGrief is not programmed to pass that information yet.
--- merged: Feb 23, 2011 11:53 PM ---
Version 0.5.1 Released:
Updated to CB 432
Now uses GroupManager over Permissions (You can switch to GM and your other plugins using Permissions will still work via the FakePermissions.jar provided with GM!)

 

+1

 

Are you going to release an update that world with permissions 2.1 alone?

I'd rather not manage another permissions plugin... especially since permissions 2.1 has good multiworld support.

 

I like your plugin very much, but Permissions 2.1 support would be highly appreciated..