@stgram Bug in that dev build. Was supposed to fix another issue that occurs when other plugins already hook a command GP wants (specifically, /ignore I think is used by essentials) GP won't try to hook it since doing so causes an Error.

In this case it thinks itself is a different plugin, which is hilarious but not very useful since it disables everything.

@Bobcat00

Many individuals required extra granularity to tweak settings for different worlds. Many Servers have a number of worlds and they don't require the same functionality from GP for each of them. Previously this separation was handled by having a bunch of otherwise hard-coded behaviours codified via whether a world was in the Survival or Creative World's listing, which limited that capacity. With separate Worlds per configuration it not only allows such configuration capabilities but also single-handedly allowed for a number of other fixes, particularly with regard to Modded servers as well as servers that have Plugins which load worlds after startup.

To address the concerns of those who find this new capacity too complex or who do not require this extra granularity, you can set GriefPrevention.WorldConfig.SingleWorld. Assigning a name to this will 'force' all worlds to load from only one configuration, so while you cannot reduce it to a single config you can reduce it to two (config.yml and a single world configuration file).

@diannetea

Horse ownership is a Minecraft feature. GriefPrevention does not handle Ownership*- it simply responds to it.

• - Well ok that's not true. you can set GriefPrevention.ExtendedHorseTrust in a world config to enable a bunch of hard-coded capabilities for Horse protections that couldn't be codified as rules, and transferring ownership will occur in some situations (Player A owns a claim, Player B tries to ride a Horse owned by Player A in Player A's claim, if they also have build trust they will be able to ride the horse and it will transfer ownership to them).

@BC_Programming

Any idea what could have caused that? http://pastebin.com/TQFkep21 That showed up after updating from 214 to 222, I got it back immediately to 220 and it worked. (could not test extensively, had players online)

@Bobcat00

You'll get used to it. BC has enough on his head, dont torment him. :) (we've been over this issue, and he knows well enough)

So with 7.8 I need to be editing 6 config files instead of only one? I don't see how this is an advantage.

@netherfoam

griefprevention.claims.blocksaccruedperhour in the world config. If a player is a world when the claim blocks are delivered (once every 10 minutes) they will receive the appropriate fraction of that worlds per hour claim blocks.

@Desertive

the /gpreload and /reload problems weren't fixed until #214. The problem is that each handler kept a reference to the dataStore (eg. claim data and player data). but when the plugin was reloaded (using /gpreload or /reload or another plugin for management) they would not be changed. The end result is that some handlers referred to one set of data, and another handler referred to another.

For example, in the video somebody else posted, a claim border is shown to cover one area, but they can place blocks within that border. That is because the dataStore's went out of sync, and then a player resized that claim. Claim resizing is dealt with in the Player Event handler. the Block Event Handler so it has a different set of claim data that was the original size. This was fixed with build #214 to the best of my recollection.

@Desertive

Thanks for that extra info. I created a second subclaim and it had the subdivision set as the owner. However it was loaded and subsequently saved with the owner name of the parent claim (this is how it is supposed to be being saved anyway,). The Owner name of a subclaim isn't even used.

That said, however, I might switch it to queue all subclaims until all the top-level claims load, and then add them to their appropriate owners after. Right now it skips all child claims and instead queries for child claims within each top level claim. Seems like a better idea to only do a single query instead. (either that, or add a condition to only retrieve top level claims for the first). The speed issue is most likely to occur when your MySQL server is remote. This is for two reasons: The main reason this would occur while the server is running (eg deleting claims) is probably because GP doesn't use a connectionpool, which is apparently some set of classes that it needs to workaround JDBC's bad design architecture. Code wise, GP doesn't open extra connections- it opens it once and that's it. But I guess maybe JDBC will close a unused connection and it will need to be reopened, or something along those lines.

The shutdown taking a long time is not a surprise- if a few delete queries (from /deleteclaim) can cause problems, shutdown will also; when GP shuts down it will wipe the entire database and then rewrite every single claim. (and playerData, I believe). This was chosen long ago, presumably because trying to keep the database up to date while making changes to the claims themselves is a massive pain. One alternative I can think of would be for claims to simply mark themselves as dirty if anything is changed... but that's going to be at least as painful. It would help shutdown since only claims that changed while the server ran would be saved (or inserted). I'm wary to make such a change because then that change will bring no end of it's own bugs and problems, and we've got quite enough of those already, haha.

@Bobcat00

7.7 is for 1.5.2 and doesn't know anything about horses. (only leads+fenceposts are protected and only because they are technically another entity).

@anfereon

enabling GriefPrevention.ExtendedHorseTrust (which I believe was added after b213 and only recently had a fix applied such that it actually appeared in the configuration file) should apply some extended functionality to horses. It is currently 'hard-coded' and I forget the specifics, but if memory serves a horse will be protected only in certain cases- being on another player's claim (other than the owner) is not one of those cases.

@Teanji

there is a griefprevention.PvP.Enabled setting, however it's only used currently (as you witnessed) for enabling and disabling PvP for that world itself. I'll revise it such that it is regarded in certain events and PvP-related logic and probably remove the change to disable/enable PVP for a world based on that setting.

@yellolegalpad

It's documented here.

"Whether you can use the admin tool. This is used primarily with Forge servers for adding containers and blocks to the container and access listings."

It probably needs to be something more obscure. Probably Fire.

Might I ask what happened to the claim blocks gain rate config setting? Eg, you can set the initial amount of claim blocks, and used to be able to set the number of extra blocks you were given per hour. Where's this blocks-per-hour setting gone? :/

I have a subclaim within an admin claim (no additional trusting within the subclaim), and people can ride horses. I thought GriefPrevention prevented people from stealing horses. I'm using CB 1.7.2 and GP 7.7 with flat file storage.

@P4kA

Thanks, you are the only person having subclaims problems to actually give me anything specific, in this case, that it only occurs in admin claims. Which is probably why none of the subclaims I have in my claims on my test server have ever disappeared. (or at least it's a difference that could be the reason for such).

You don't however mention what version of either the plugin or Bukkit you are running.

EDIT: I should be clear that the first paragraph was NOT a passive aggressive note against stgram at all, though it does read that way. I just wasn't able to reproduce the issue which is not helpful if folks are in fact experiencing it. (Me not being able to reproduce the issue doesn't make it go away if others are experiencing it) which is why I was silent on that particular thing. More information is needed since it's much easier to try to fix stuff if I'm able to find out how to reproduce it (which is why I added a bunch of subclaims when the issue was first reported, and they haven't disappeared).

some other useful stuff from anybody experiencing disappearing subclaims would be what data store (flat or MySQL) is being used and any other observed patterns (such as the mention regarding administrator claims).

BC, I may not be up to date on the item frame situation but I wanted to report that in the current beta, Creepers can still blow items out of their frames.

While we are on the subject of Creeper grief, horses seem to have no provisions protecting them from griefers that would lure creepers. My suggestion would be to prevent creeper damage to tamed horses if the owner's getVehicle() is not the horse. That way they can still be damaged while being ridden.