@cheracc

just popped that off into the next dev build just now. I replied to the ticket with a bit more info and, in particular, some of the new configuration settings applicable for the setting. (short story /plugins/GriefPreventionData/WorldConfig/<worldname>.cfg is now where you will find most settings.

@marubal21

"but does it mean that a player can still use enderpearls within a claim"

Yes. If the destination location is inside a claim that the player doesn't have access trust in, the teleport is cancelled.

@marubal21

When you have it set you have to have access trust on a claim to teleport into it with an enderpearl.

@CayleRose 1. It's a dev build. 2. It's a dev build from May 11th.

I'll have to repro the AbandonClaim issue, that might still exist.

@Senophoe

For some reason they are using a dev build from before build #29, which is around when I removed the "checking player matches" debug output.

Also, Thanks for your testing, I'll look into those discrepancies.

WitherEating is supposed to configure which blocks the withers can eat. Withers 'eat' blocks to get at their targets.

Wither explosions should include both the large explosion Withers make when they fully charge as well as explosions from their Wither skull projectiles.

"Other" explosions is used for any explosion that GP cannot identify. Presumably this would occur most frequently for modded servers.

I'm also going to add similar 'option sets' for where withers and the golems can be spawned (ideally dropping the used blocks when they are cancelled). Many other options are ripe for being expanded to this once I resolve current issues. Options I plan to expand to this new setup would be many of the current true/false settings:

EnvironmentalVehicleDamage,PreventTheft,PreventTrades,ProtectCreatures,PreventButtonsSwitches,LockWoodenDoors,LockTrapDoors,LockFenceGates,EnderPearlsRequireAccessTrust, etc.

@Senophoe

Latest dev build implements a new "framework" of options. I got to thinking about the problem, and what we have are several "actions"  that we want to define as being possible inside and outside claims and above or below sea level. My solution involves creating sections for each of these settings. For example, I've moved several options into their own sections (and added some new ideas that I haven't yet implemented, too):

GriefPrevention:
  CreeperExplosions:
    BelowSeaLevelWilderness: true
    BelowSeaLevelClaims: false
    AboveSeaLevelWilderness: true
    AboveSeaLevelClaims: false
  WitherExplosions:
    BelowSeaLevelWilderness: true
    BelowSeaLevelClaims: false
    AboveSeaLevelWilderness: true
    AboveSeaLevelClaims: false
  WitherEating:
    BelowSeaLevelWilderness: true
    BelowSeaLevelClaims: false
    AboveSeaLevelWilderness: true
    AboveSeaLevelClaims: false
  TNTExplosions:
    BelowSeaLevelWilderness: true
    BelowSeaLevelClaims: false
    AboveSeaLevelWilderness: true
    AboveSeaLevelClaims: false
  WaterBuckets:
    BelowSeaLevelWilderness: true
    BelowSeaLevelClaims: false
    AboveSeaLevelWilderness: true
    AboveSeaLevelClaims: false

Each of these options now has FAR more granular control. eg; you can now configure it, if you want, to only allow TNT explosions within claims below sea level, or only allow it outside claims above sea level, or allow it outside claims above sea level and inside claims below sea level, or only allow creepers to do damage in claims below sea level, etcetera. Many options will be moved to this form (water and lava placement, primarily). Allowing for, hopefully, very fine-level control over numerous configuration options.

These are also world-specific. Onto that particular implementation. World configurations will be saved/read from Plugins\GriefPreventionData\WorldConfigs\<worldname>.cfg. Some notes:

-It doesn't currently read existing options from config.yml This is because I'm  basically reworking a lot of the options to be more coherent (IMO). As a result I recommend, if there is an existing config.yml file, backing that file up before you run the later dev builds.

World configurations are only read in and created on an as-needed basis. If the configuration file for a world is not found, GP will either create a "new" configuration file using the default settings, or it will create a new set of settings based on the contents of _template.cfg in the same folder. This allows players to create default configurations for worlds that do not yet exist, which can be useful both for standard management tasks as well as dealing with plugins that create worlds.

As with any dev build- and in many ways, more so with this one due to the extent of the changes, there are numerous issues; some chat messages are doubled up (due to the changes I made to logic) as well as some messages no longer being applicable. I will make changes and add messages where they seem to fit, and the configuration options will be changing dramatically over the next while as we work things out.

@Talidorn

You could do that yourself. Just add griefprevention.ignoreclaims to permission to everyone and /reload griefprevention.

Then remove it and reload again when your done with "the purge".

@WolfyRetroKnight

You might find GriefPreventionFlags, a separate plugin that adds some additional claim-based features, useful for those features you feel it needs:

http://dev.bukkit.org/server-mods/gpflags/

@Josef27

Another user had similar performance issues which we traced to some of the cleanup tasks; I believe the one causing their issue was either the EntityCleanupTask or the Claim cleanup task. I forget the specific build they used, but the current dev build should have a configuration option to disable these tasks. If memory serves me, the new configuration options should appear if you run the latest dev build (without replacing your current settings), "GriefPrevention.CleanupTasks.Entity" and "GriefPrevention.ClaimCleanup.Enabled" would be the Configuration path on the config.yml file. to these options.

You can find the latest dev builds here:

http://build.yu8.me:8080/job/GriefPrevention/

EDIT: You might want to use Build #40, since the later ones completely rework how configuration data is dealt with

@confuser

Tux2 forked the project from the original repo listed on the repositories page. It can be found here:

https://github.com/Tux2/GriefPrevention

I'll add it somewhere in the main page.

As for events, I agree. I'll add extra fields/getters/setters once I'm finished testing the newly refactored configuration code to allow for world-specific configurations.

As for the public API page, it looks like it was last edited before Events were even added, which might be why none are listed or explained. The current events are:
ClaimDeletedEvent
ClaimModifiedEvent
ClaimResizeEvent
NewClaimCreated

which fire when one would expect. And no I have no clue why it's called "NewClaimCreated" when it ought to be called ClaimCreatedEvent. When I get around to fiddling with the events myself, I'll likely deprecate NewClaimCreated (so existing code doesn't break) and create a new ClaimCreatedEvent. I'll likely make appropriate edits to the public API page at that time.

Me and Tux2 can also usually be found on the irc.mibbit.com IRC network in the #pinoygamers channel.

Could you please list the events within the Public API page? Also you state that the source is available, but a link to it on the main page is no where to be seen. A lot of the events seem to be missing basic functionality such as getPlayer etc.