@BC_Programming

"regarding the player.dat cleanup, that's just a result of deleting the player.dat files. I can think of some ways to address this; for example if while loading claims there is no player.dat for the claim owner, it could delete that claim."

^PLEASE ADD THAT! Here why:

Say I wanted to delete claims of players that haven't been online for so-long, right? I could just sort all the player.dat files by "changed", shift-select the old ones, and bam! Two cleanups in one. :) Please, you gotta' have this added sir.

@numskull34

Referring to the Looting of chests inside a claim after the defender has been defeated, that should be in the dev builds already, the config option is world-specific, and is "GriefPrevention.Claims.SeigeLootChests". 0 means to not allow any opening of chests for looting, and is the default, higher entries means (or should mean) the ability for that many chests to be opened.

@n33dy1

The way it is now, it's done for performance reasons, because in calculating the "investment score" of a claim, the plugin has to analyze every block, which can get pretty intensive. I believe in some dev builds I added configuration options for the investment scorevalues. If set to 0 I think it would clean up any claim that comes under the "time to cleanup" microscope, which relies on the time since the owner last logged on and whatnot. In fact if it's set to zero it skips the investment calculation altogether, too.

The reason it's spaced out so much is because it actually takes a very long time to calculate. There were several reported issues with the default setting where GriefPrevention was actually pegging the java process almost full throttle; since it has to perform the checks on the main bukkit thread, that means that while it checks the server is "frozen". In that particular instance the administrator of the server was reporting that players were getting constantly disconnected and their server CPU was throttled at 100%. I did make some adjustments and I may have actually made that delay configurable already, but a quick check shows that it's still hard coded at 5-minute intervals.

If you want to "aggressively" cleanup claims, you might be able to set the "GriefPrevention.ClaimCleanup.MaxInvestmentScore" (in the dev build) to 0, which will force a lot of claims to be cleaned up.

Currently there is no cleanup of player.dat files, which track a bit more data than just what claims they have. It's worth noting that soon after Tux2 was given project control he reworked some of the claim and player search algorithms, so generally speaking having a lot of claims or players won't affect logic that has to search for specific claims. For claims, they are indexed by the chunk they are in; so retrieving a claim for a specific location is a matter of looking up the Claims for that chunk and then only checking bounds on those claims. Player data is indexed by player name using a HashMap, so more players shouldn't cause scaling problems. Of course they do clutter the data directories, so it makes sense to provide some sort of admin-oriented command for forcing claim and player data purges. (/ForceClaimPurge and /ForcePlayerPurge with appropriate permission requirements are what I'm currently thinking).

regarding the player.dat cleanup, that's just a result of deleting the player.dat files. I can think of some ways to address this; for example if while loading claims there is no player.dat for the claim owner, it could delete that claim.

The max accrued blocks are checked when Claim blocks are delivered (or they should be), that is, if claim blocks are "delivered" (through the repeating task which gives claim blocks at intervals), and the number of claim blocks that player has exceeds the maximum, it is set to the maximum. It's not checked when the player data is loaded for some reason, which it probably should do. I don't think a command really makes sense for that, since the claimblocks should never exceed MaxAccruedBlocks by definition.

@BC_Programming

Holy crap any way to change that? I restart quite often...

If I could set mine to check every 30 seconds and ignore the tolerance, that'd be great!

EDIT:

I also sorted my player.dat files in my world folder and deleted hundreds of users that haven't been on in months.

When I do /deleteallclaims PlayerWhoHasNoDATFile it says "Player not found."

EDIT 2: (add this?)

If player's blocks exceed MaxAccruedBlocks, set it to MaxAccruedBlocks. /ShaveBonusBlocks playerName

@n33dy1

Claims are never cleaned up if they contain chests, are larger than 20 in either width or height, or contain some specific tolerance value of blocks. (some blocks, like lava, make the score go down in value, most player placed blocks such as bricks and cobble make it go up).

The claim cleanup task checks a single claim every 5 minutes. or so. Depending on your uptime that should mean it would go through all claims once every 6 or so days.

@numskull34

An interesting idea. Though I have not had the oppurtunity to test it, in a relatively recent dev build I intended to add a feature whereby a certain number of chests can be opened by anybody on a defeated players claim for that cooldown period. So for example of the value was set to 3, then three chests could be opened in total, and once that limit is reached attackers would not be able to plunder any further. I'm not sure if this would provide the same sort of gameplay mechanic you are after, though.

I checked my ClaimData folder and found out I had 1,900 claims. I sorted by change date, checked for the owner of each claim, did /seen on their username, and had to manually do a lot of /deleteallclaims playernamehere Can you tell me when the old claims are purged? I know there are options for this in the config.yml but I mean when do they get purged? Every so-many minutes? On restarts? When?

Also, can we get a /purgeoldclaims command? Not sure why mine won't delete the hella' old claims of over 4 months old.

    Expiration:
      ChestClaimDays: 20
      UnusedClaimDays: 30
      AllClaimDays: 20

@audiophoenix Since there isn't a bukkit build for 1.6, I'm going to say no. Once there is it will mean adding support for the new elements as needed.

@rawrlehel

OK, I recall resolving some world-specific issues with claims disappearing recently, and then they reappeared in another build and needed to be fixed again.

@audiophoenix You aren't missing anything, because I haven't documented the world configuration stuff yet. Or, rather, I have, but I haven't finished it and published it in any manner yet. And since the feature is in a state of flux, new rules are added, some are changed or removed, defaults change when we realize that the default doesn't make sense, etc. It didn't seem entirely beneficial to try to document something that was changing, since a lot of it would need to be rewritten anyway.

If you are using 7.7, then you aren't dealing with World-based configurations, though, I'm quite certain the version was changed to "7.8" for dev builds before that change was made.

To try to clear up your confusion, I'll paste the part of the configuration docs that I have written so far that cover the various "Rules" entries in the configuration- The rest of this post is a copy paste of that particular section.

GriefPrevention.Rules

Dev build 90 has moved the "rules" to a separate category in order to prevent them from getting mixed in with the others. This section is filled with a heirarchy of values that indicate various rules for all sorts of behaviours. All of these entries have their own set of sectional data. For example:

GriefPrevention:
  Rules:
    CreeperExplosions:
      Wilderness:
        AboveSeaLevel: Allow
        BelowSeaLevel: Allow
      Claims:
        AboveSeaLevel: Deny
        BelowSeaLevel: Deny
        ClaimControl: Disabled

The rule here is "Rules.CreeperExplosions". And this rule is used to determine where creeper explosions are allowed. This setting allows Creeper explosions to destroy blocks in the wilderness, but not inside claims. Valid values for the AboveSeaLevel and BelowSeaLevel properties are Allow and Deny.

The Claims.ClaimControl setting deserves some additional explanation. This setting is on all of the Rules values, but it is only valid for rules that will involve a Player. in this case, a Creeper Exploding does not involve a Player, and so the setting for Claim Control here is not used. For rules that do involve players, however, this can be used to require a specific level of trust inside claims for that Action. Valid values for ClaimControl are RequireNone, which means that no claim check is performed at all and it should be allowed. This will force this action to be available to all players. RequireOwner,RequireManager,RequireAccess,RequireContainer, and RequireBuild, which require the player performing the action to have the specified trust in the claim. "Disabled" means to not perform claim checks. If a claim check is performed, it will be rejected and a Message shown saying that configuration is disabled. This compares to None as the direct opposite; RequireNone means to unilaterally allow the feature; Disabled means to unilaterally disable it. For example, If you set the GriefPrevention.Rules.LavaBuckets entry as such:

    LavaBuckets:
      Wilderness:
        AboveSeaLevel: Allow
        BelowSeaLevel: Deny
      Claims:
        AboveSeaLevel: Allow
        BelowSeaLevel: Deny
        ClaimControl: RequireOwner

This will prevent players from placing Lava buckets below sea level in the wilderness. For claims, it will prevent any placement below sea level, and it will only allow players that Own the claim to place lava above sea level. In this way you can consider "Claim Control" to be regarded only if the Sea Level values have been checked.

@ManBeastPigDev

That's not really enough information to work with :/

Can I increase the amount of blocks a player gets per hour on a per player basis? Giving players with a higher rank more blocks would be a nice feature.

Attempted to add maven support and capabilities. The jenkins build may fail because I think the jenkins configuration for GriefPrevention may need to be changed. Sorry for any inconvenience if this is the case.