This may sound like a giant “duh” to anyone coming from Bukkit, but anyone who’s run a modded server with Bukkit plugins before can tell you that anti-grief is a nightmare when mods are permitted to directly impact the world and players without consulting with other (anti grief) mods/plugins first.
Tekkit was the infamous example - certain parts of Tekkit weren’t calling the provided Bukkit integration API’s for block changes and entity events, which made it impossible for Bukkit plugins to cancel those events based on anti-grief rules. For example, using the “destruction catalyst”, any griefer could walk into a land claim that he was otherwise unable to modify due to not having permissions and instantly wipe the whole thing out with a couple of right clicks. Server owners eventually got wise to this, and their only option was to disable large parts of Tekkit which were known to be problematic.
This was bad for players because server owners on the learning curve left their players open to grief which could not be prevented or rolled back, except by a whole-server rollback based on a world backup, AND some of the coolest toys made available by popular mods were not available to them, much to their disappointments. It was bad for server owners because they had no general anti grief tools to trust - they had to be absolute experts in every mod they installed, and configure them exactly right to avoid a major griefing problem.
So my suggestion is to fire a cancelable event for ALL changes to the world and entities in it, without exception for any plugins/mods (meaning there would be no Sponge API which does not fire the event and respect cancellations before allowing the changes). Otherwise, we’ll be right back in the sinking Tekkit boat again, this time on a wider scale because modding for client will be so much easier.
Some specifics:
Any event should be tied to either a block (e.g. fire spreading from a source fire block to a destination non-fire block), or an entity (tnt or creepers exploding blocks, players placing or breaking blocks). The only exception would be during chunk generation, where we know it’s not grief because no players haven’t had an opportunity to influence the event. Even natural events can be modeled this way - blocks added by tree growth can be tied to the sapling that rooted the tree, apples growing on a tree can be blamed on the leaf block above the new apple. Blame water freezing on adjacent ice blocks, or snowy air above.
By doing this, we can assess whether the event should be allowed to happen based on the source entity/block - a tree rooted outside a land claim can’t add blocks inside a nearby land claim (it might have been planted by a griefer with intent to change the claim), a creeper can’t destroy claimed blocks unless he’s chasing someone with build permission in the claim, a player can’t shoot some crazy magic ring to wipe out claimed blocks unless he has build permission in the claim, and a player can’t hurt an animal in a land claim with an arrow unless he has permission to kill animals in the land claim.
For example, consider these signatures for block and entity health changes, which include required parameters for WHO or WHAT is responsible for the change:
world.setblocktypeanddata(location, newtype, newdata, sourceBlock)
world.setblocktypeanddata(location, newtype, newdata, sourceEntity)
entity.setHealth(newHealth, sourceBlock)
entity.setHealth(newHealth, sourceEntity)
In the above, sourceBlock and sourceEntity cannot be null, and in the case of block changes, the sourceBlock can’t be the same as the block being changed.
With this somewhat generic information about the source of world changing events in place and a guarantee that they will always be cancellable, it’s possible to implement generic anti grief which will effectively prevent grief no matter which mods or plugins are installed. But it only works if all plugins/mods follow the rule about asking other plugins’ permissions first, and that will only happen if it’s made unavoidable by the API.
Thanks for reading my lengthy post.
I will be porting GriefPrevention over to Sponge, and it will offer the same amazing preventative anti-grief features it offered to CraftBukkit server owners for Vanilla grief. Whether it can offer the same level of preventative protection for heavily modded Sponge servers will depend on whether Sponge implements the API to guarantee these events are cancellable and enough metadata is available to make informed decisions about potential cancellations.