@dinomite536

Delete/rename your GriefPrevention/config.yml file.

The "ClaimCleanup" section is for the Automatic claim cleanup logic. By default, this logic appears to examine one claim every minute to see if it is valid for automatic cleanup and/or nature restoration. As it was previously coded, it had a hard-set limit that meant that any claim wider or longer than 25 blocks would be skipped for performance reasons. I simply moved those options to the configuration file for adjustment if necessary. Each of them refer to the size for worlds that have Creative or Survival rules enabled.
the "MaxInvestmentScore" entries are used in the same logic. This is one of the priciest parts of the claim cleanup, since investment score calculations involve iterating over every block within the claim and determining how "invested" the player is in the claim by giving scores based on the number of chests and unnatural blocks in the claim. It also gives a sharp penalty for any Lava Blocks above sea level. Off the top of my head I believe it subtracts 10 points for each Lava block above sea level, adds 10 points for each chest, and adds half a point for each unnatural block below sea level and a full point for those above. This result was originally compared to hard coded values- 400 for Creative rules, and 100 for Survival Rules. I've moved those values to be configurable.

Additionally, setting the value to 0 for one or both of them will entirely skip the Investment score calculations and instantly cleanup claims of users that haven't been online in the number of days set in the config file via the UnusedClaimDays and ChestClaimDays settings.

ClaimCleanup:
CreativeMaximumSize: 25
SurvivalMaximumSize: 25
CreativeMaxInvestmentScore: 400
SurvivalMaxInvestmentScore: 100

Expiration.MessageCooldown.Claim and MessageCooldown.Stuck entries are used for the pattern matching of stuck/trapped and "claim" words. Previously, for example, every time you typed Stuck or trapped or another matched word, you would get a message telling you about the /trapped command or about basic claiming. I recall some requests to allow for a configurable timeout, which is what these are supposed to work as. the Claim timeout is the number of seconds before it will show the message again for a player after showing it; the option is very much the same for stuck.

Claims:
PreventTrades: false
PerPlayerLimit: 0

when "PreventTrades" is on, trading with Villagers on other people's Claims will require Container Trust. Otherwise, attempting to trade will give you the standard "you do not have <player>'s permission to use that"

PerPlayerLimit is the maximum number of claims a player can have. 0 means that there is no limit.

The additional feature designed for this is that when NoBuildOutsideClaims is enabled, this will also prevent trading with Villagers outside a Claim. What this would end up meaning is that players would need to claim an area or get containertrust on a claim with villagers on it before they can trade. with them. Looking at it to determine the logic, I've determined it's actually broken and won't prevent trades in that case. That will be fixed in the next build.

Trashblocks are the blocks that, when placed outside a claim, will not trigger the "other people can undo your work" prompt.
WildernesswarningBlockCount is the number of non-'trash' blocks you have to place before it shows the message again.

In the next build this list will also be used when "GriefPrevention.Claims.NoSurvivalBuildingOutsideClaims" is set to true, in which case it will be the list of blocks that [i]can[/b] be placed outside of claims. (other blocks will be disallowed entirely). The purpose being that this allows players to place furnaces and make small, simple bases as they mine.

@JerryFord

This is partly why I think the feature is currently redundant. It doesn't actually have groups in the configuration file and instead creates "groups" based on who has GriefPrevention.trustgroups.<groupname> permissions. I didn't realize the plugin already had support for Permission-based trust by using things like /trust [permission.node]. I'll probably change it over to use a configuration section, which I was going to do originally. Most likely the section for trustgroups will look something like this:
trustgroups:
- Donators
- Playerguy
- Otherplayerguy
- HalfOps
- ChickenMan
- Mr.Kibbles

with Donators and HalfOps being the two groups, in this case.

I'm also a bit skeptical about just how well the newer "deny" flagging will work. If it works as designed, you should be able to use /trust !playername The purpose of this being to allow for subclaims to remove permissions and also allow the ability to say, give a group or people with a given permission access to a claim while excluding members that would otherwise match one of those groups. Ideally this would also involve prettifying some of the claim display, particularly those from trustlist, or even making the flag invisible altogether, say perhaps with a /denyaccess or /denycontainer or /denytrust commands.

I believe I also added a /gpreload command to the latest revision, which is supposed to allow the cfg file to be reloaded at will. Right now it just calls onDisable() and then onEnable(), so I don't know if it will work as intended.

@meiamone

I added the "groups" feature a few days ago. I saw it on a ticket first, though can't be bothered to see if it was you. I'm not even certain it was required, since the plugin seems to have already supported the ability to use permission nodes wherever you trust or untrust players; for example, you could use /trust [Permissions.Donator] to give permissions to only players that have that Permission. I don't know how redundant that made my additions, however so I just left in the added 'Groups' Capability.

@Feeriix

Some of the dev versions allow for the customization of "Trash" blocks, which are the blocks you can place outside a claim without the warning message. Since the "nosurvivalbuildingoutsideclaims" option makes those TrashBlocks a bit redundant, I'm thinking of using them as the "whitelist" for what blocks you can place at all outside claims, instead of adding a completely separate whitelist option.

@IndigoParadox You've provided no details. And absolutely nothing to work with. If you are in fact using the build for 1.5.1, it's not exactly ground-breaking that it doesn't work properly on 1.5.2.

@LeeTheENTP

I wasn't able to figure out how it would have allowed the ability for a subclaim to deny permissions. Perhaps there was a revision that temporarily changed something else which had the side effect of disassociating subclaims from their parent? The way the data structures are setup the only way that would happen is if they were dissassociated and subclaims didn't call into their parent, at least as far as I understand the implementation.

I added the flag prefix idea. I've not done any of my own testing, so it's more a "seat of the pants" build right now. The trust commands should now be able to accept names starting with an exclamation mark to explicitly deny that trust in the claim. For subclaims, this means it won't defer to the parent if it finds an explicit denial.

I figure this is useful for other reasons- and I can probably wrap handling behind special /denyaccess, /denycontainer, etc commands, which will add the name as an explicit denial for a subclaim, or, for normal claims, just remove it from the appropriate list.

This also (partly) addresses the recent addition of groups as well as the existing ability to trust players with a specific permission. explicitly denying a permission with /trust !name before giving permission to a group in which that player is part will still deny permission to that player, but allow the other members of that group. I'll probably make changes so it's not dependent on the order of the names in the list, since right now you have to add the denial before adding the group.

@BC_Programming

I'd appreciate it if you could restore that functionality, because people on my server have been missing it.

EDIT: Couldn't you give each future subdivision in each claim a unique ID, and add a fix-it command that goes through all the claim files and add an ID for each old subdivision?

@sshaggy

I do not believe GP can do this because as stated above, "Some Tekkit items and blocks completely bypass all Bukkit plugins, which means they bypass any anti-grief code, are not logged by block loggers, and can't be rolled-back by block loggers."

Unfortunately, this is the case with Tekkit as well as other mods and modpacks.

Correct me if I'm wrong, because that would certainly help this guy.

Side note: I'm looking into how I can make subclaims have some sort of reasonable inheritance without having to make sweeping changes. I also may be wrong entirely about the implementation TheShadBusher. I honestly hope it is a bug and there is a missing check somewhere that restores the behaviour you recall, because otherwise the design of subclaims is pretty silly.

What I've found so far is that claims are saved with a list of players with each trust permission. A player name being present means they have it, and one being not-present means they do not. Which has the rather interesting problem for subclaims- how do we know if an absent name means to inherit from the parent, and when it means somebody was explicitly denied permission? I'm not sure how to approach this. The one thing I can think of would be to make it so that names that are added in those lists that start with a flag character mean that that player was explicitly denied that specific permission in the claim. This won't affect how the data is stored and might be a workable way to get the desired ability to override and prevent inheritance- additionally other code that uses the lists won't accidentally match names and give perms because ! is not a valid Minecraft player name (as far as I'm aware).

@dinomite536

What version of GP are you using?

@LeeTheENTP

What I mean is it's working exactly as designed. It's just designed in a ridiculous way, and you expect it to work a different way. (that different way being "reasonable" rather than "ridiculous").

"I used to be able to give trust in the parent claim and clear the trustlist in one of its subdivisions, and the person couldn't do anything within that subdivision."

Hmm, you sure that was with GriefPrevention? Looking through the Commit history (all the way back to GP 3.2) and I find no changes to the source that would explain how that would have happened. Unless it was before Version 3.2, my interpretation of the logic tells me that subclaims could only ever add permissions. Each claim checks if things are allowed based on it's own settings, and if so it returns null (indicating permission is allowed); after those checks, if it has a parent claim it simply returns the result of the same permission from that parent. Subclaims have not allowed the denial of permissions since at least GP 3.2 (most likely before that, but I think that was when it was originally put on github by BigScary). You might have been using another Protection plugin? I'm sure at least one other Protection plugin has subdivisions/subclaims that aren't implemented as hackishly.

Ideally, of course, subclaims would allow changes either way. IMO any other implementation is downright ridiculous and defeats the purpose; subclaims should either allow, deny, or inherit a given permission- when you create one it should default to inherited so it's the same as the parent, but if you make changes, those changes should take precedence.

Based on the source going back to GP 3.2 that functionality is the same. Child claims cannot remove trusts and permissions from their parent claim, they only allow. The one exception appears to be Permission trust, which seems to allow subclaims to have their own set of Managers. (this completely arbitrary selection of what inherits what and when is why I think this was originally a quick hack that wasn't really thought through, at least in terms of a parent->child relationship and appropriate permission inheritance)

The best workaround I can think of that would be the easiest to implement would be to make subclaims inherit all their parent claims permissions when they are created, and then not defer to their parent for permission checks. This seems like a reasonable compromise, since otherwise it would require quite a few changes, including changes to some of the underlying data Storage, where I'm sure dragons are living and which will cause me to corrupt people's Claim databases and make me feel bad even if Dev builds come with that sort of inherent risk.

From what I can tell subclaims appear to be something that was added as a quick hack and had features pasted onto it since, which has snowballed into a big issue. They complicate pretty much every piece of logic involving claims, make identifying them uniquely across server restarts from other plugins impossible since they don't have an ID, their perms don't work reasonably, since if they were a subclaim they ought to allow for either explicit allow OR deny permissions, in addition to inheriting from the parent by default, whereas right now they only can be used to allow more perms. That isn't to blame anybody that has contributed or made those changes, of course- just that it appears to have snowballed over time.

@CrossfireLR99

Disable SmartBan in the config.