Is there a way to accesstrust everyone? Like when I want everyone to be able to access chests on a certain claim but not mine them up..

Is there a command to unmute a muted player?

Is it possible to make a utility (External from bukkit or not, I don't care), and have it migrate SQL stored data to flatfile? I know the plugin already migrates flat to SQL. Reason I ask is that for some reason most of my subclaims get reverted/deleted on EVERY reload or restart. GP also has a tremendous load time (presumably because of the SQL connections), and usually fails to disable (same reason I'd guess), and I think it's not successfully pushing SQL queries, and I'd rather not lose all claim data by reverting to flat file at this point, and I'm extremely exhausted of re-creating tons of subclaims and trusting people every day, considering it is still rather laggy to do so when using SQL. Thanks!

Whats the in game command to give players claim blocks?

@Wisteso

I cannot seem to find it but there was either a ticket or perhaps a PM conversation in which we addressed some of those performance issues. Particularly the ClaimCleanupTask. I am uncertain if the EntityCleanupTask was changed to address that same problem. This was post 7.7, which according to your timings is what you are using. Specifically ClaimCleanupTask was changed to process 1 claim rather than a certain percentage of claims. the calculation on a claim could occasionally be quite intensive (particularly when ti calculates investment scores) so this would cause lag issues. In that particular users case, they had so many claims that it actually took long enough for the task to run that by the time it finished it was time to run it again, which basically killed the server entirely. It was more or less the end result of the sort of thing you are seeing scaled up to far more claims.

Those were pretty much the first thing I removed when I was looking into it, while swearing under my breath. The JVM knows better than we do when it's best to perform a GC, after all.

If you can get similar timings with the latest dev build, on a similarly configured server, that could help. the actual execution time hasn't caused problems for a while, but I believe the performance changes have caused claims to remain uncleaned for longer periods of time. (It processes fewer claims per iteration so if there are around 300 claims in a world it will take an entire day for them all to be checked to see if they need cleaned.

I haven't looked at EntityCleanup since I commented out the System.gc() so it may still be causing issues. It could probably be changed in a similar way to the Claim cleanup such that it will check a given number of entities rather than a percentage thereof.

@confuser

Correct. I Didn't install it and I don't know how to utilize it. I just fumbled around and it might show up if I approve a build as a maven repo but The less time I even read the word "maven" the better.

The event was added by Tux2. It is not in the upstream repository (https://github.com/ryanhamshire/GriefPrevention/).

Based on the commits it looks like it was in 7.7 however I specifically recall them not being fired when I created a test harness dependent plugin. Either way, since they were added After Bigscary retired and passed it on the Tux2, I don't see how they could be on his jdocs site.

When I did fix them so they were fired, it was notable that NewClaimCreated implemented Cancellable however it was trivial for a handler to throw things for a loop if it resizes or otherwise creates a claim within it's handler. Additionally, the Claim object wasn't truly valid when the event was fired since it was not within the dataStore and did not have a valid ID until addClaim() was called; however, the reason addClaim wasn't being called was because the event's Cancellable was being used to determine whether to actually cancel the addition. Additionally, the way it was written made it implicitly not re-entrant- if the event handler created a claim or resized a claim, the claim for which the event was first fired would now already exist in the dataStore, so it would overwrite the existing claim, but both claims would remain in the in-memory dataStore.

Indeed. I've seriously considered rolling everything back to 7.7 and adding some crappy support for horses using overly long configuration nodes that caused special case logic to be run in a manner that was heavily unconfigurable by design, to fit in with everything else. More fool me for completely refactoring how claims are loaded such that modded servers using GP can also have claims in Mystcraft or other modded worlds and reworking configurations for added flexibility as well as per-world capability.

I'd argue that "Your 7.7 configuration files will not be used." effectively says that.

"Your 7.7 configuration files will not be used." If it's too much of a bother you can just use 7.7 still. In fact the reason it duplicates the folder for 7.8 is because I knew folks were going to expect it to be a silent upgrade- like most other versions. This way if they realize they didn't put enough time aside for essentially setting up a new plugin, they can just plop back the 7.7 jar and go with that until they cna make the time (or, alternatively, until they find another plugin that meets their needs better). There have also been forks created which I would guess add the aforementioned new version support by simply adding a few configuration nodes to the previous version, while remaining blissfully uncompatible with either Forge mods that create worlds or even Bukkit plugins that create worlds (which simply might not matter).

"Your 7.7 configuration files will not be used.". I considered stating it more explicitly on the 7.8 configuration page but I figured that was pretty much covered by "GriefPrevention will revamp almost entirely the way configurations are handled.".

??? I can only guess this is supposed to say "lack of documentation of these changes". And I would tend to agree.

Aside from some missing documentation added since the build for which the documentation page was last updated, the only 'problem' is that I haven't effectively re-written some of the guides that are present for 7.7 and earlier.

And fundamentally, I can't. those guides were written by BigScary, who wrote GP primarily for himself because he ran a server.

[i]I've never run a bukkit server[/i]. Nor do I have the inclination to do so; and I hardly even play Minecraft at all these days and when I do it's SSP; basically in terms of writing guides geared towards what admins setting up the plugin would need to do, I am not qualified to write those documents. I can document the permissions, commands, and configuration as well as how the plugin works, but I cannot reinterpret that information into the style of guide we have for 7.7 very easily.

The first permission discussed in the document is "griefprevention.commands.<CommandName>" which is likely the one you omitted. The permission in question would be griefprevention.commands.deleteclaim, (if you mean the /deleteclaim command, of course).

Nothing I said in that response was passive aggressive. However it would seem some of my statements with regard to the NewClaimCreated event were possibly erroneous, as it may have been being fired. That said, It was fundamentally broken in that it was a dataStore disaster waiting to happen, as well as effectively passing a Claim instance that was effectively in Limbo. (Also: People mentioned this issue both in IRC as well as through tickets, so I addressed it.

Then by all means, continue to use 7.7. :) I would suggest finding one of the forks which (I would hope by this point) adds Horse support to the earlier version, as I mentioned earlier.