If I get an older version of GriefPrevention, will it make it so players don't have to claim land or do /ignoreclaims to build in all worlds?

@stgram

That could work.

I've tried a few times to revise some of the configuration such that it can "inherit" settings. So each world config could specify that it inherits from say defaults.yml, (which it would probably do by default) and then only the settings that change with each world would need to be specified in each world config. It got fairly messy and I threw it out because it just didn't work very well and was prone to issues. In particular, you couldn't jump in and change a setting and any new settings had to be introduced into the configuration manually, copy pasted, etc.

@ondaedj

What have you changed? In particular, what settings? if you are using b213 (the currently available beta) there are a handful of settings that are not persisted properly. Off the top of my head the settings for player protection in land claims and admin claims.

If you change a world configuration and save it it will apply when you either restart the server or /gpreload. The Single World Setting can be set to make all requests for a world config get redirected to one world configuration. for example if you specify "world" in the single world setting any request for a world configuration will use "world.yml".

dataconfig.yml is part of a larger push to add new data storage methods beyond flat and MySQL (and reintroduce Postgres support, too). It will contain the settings for the active Datastore. for MySQL it needs info like hostname username and password, but for flat it doesn't need any other data which is why that node is empty.

@Alshain01

Doesn't the template file in config.yml cover this, though? It's a bit fiddley in that it will only be used for new files, but if a config file is created it will default to whatever is in the referenced template file.

@Maximvdw

7.7 does the same thing in the situation. The only difference I suppose is that in order to generate config.yml such that you can change the data store, you need to run the plugin, and it defaults to a flat file data store so those folders will be created and used if the setting is changed to MySQL.

I'd relent that this is a terrible new feature, if 7.7 didn't do the same thing. (eg. fresh install->sets and creates flat file data->change to MySQL->MySQL data is wiped and replaced with nothing).

That's weird considering 7.7 reads in every single claim and keeps every single claim in memory for the entire run of the server whereas 7.8 will read in and discard claims as claims load and unload.

Just to fiddle about, I decided to check. 7.8 starts at 380.3MB of usage. After 15 minutes of me joining with my account and my alt account the memory usage bloated to 379MB. So either your "100MB a minute" claim is hyperbole, false, or there is something else going on with your server. testing with 7.7 and I was hoping it would use more but it uses nearly the exact same amount.

it is notable that Commit charge jumps up by around 50MB when the claim cleanup task forces a gc. Seems counter-intuitive but that's usually what happens when you force a gc cycle. One thing I can think of is if you have a plugin that generates worlds, like for arena's or something, since each one will build a new config that will stay in memory even if that world unloads. Though I'd expect the worlds themselves to be the main consumer of memory in that case, rather than GP's config data.

Hmm, so, taking that to it's logical conclusion, would not the best possible result be to remove every single configurability aspect, and have every behaviour entirely hard-coded? Of course, you would not agree with such a thing.

Fundamentally the complain in this regard seems to boil down to how other people's needs for the Plugin are being addressed. Since you do not need world-based configurations, it's just a mess to you.

Conversely, those who didn't have world-based configurability (beyond a few lists in the config.yml) found GP a massive pain to work with because of it's inflexibility.

The weird thing is I partly agree that the configurations could be confusing.

Then I installed Essentials. It's like comparing jaywalking to murder.

just 1 config to control pvp,explosions

Oh. Just set SingleWorldConfig to "world" in config.yml. Then you can change the 'world.yml' configuration file to affect everything.

>Then it added support for world specific config, but instead of changing the whole plugin they just made it possible to "add" a file with specific world configuration.

WorldGuard to my recollection has a Forge version, so their Bukkit version does not need to support MCPC+. GP is not going to have a Forge version- At least not one managed by us, so some of the changes were actually made to better support Forge servers. Some might argue that does them no good, since they don't use Modded servers or Forge. Neither do I! But it's something that had enough votes, comments, and questions that it begged to be addressed.

If you only want to configure things in one spot you can set a SingleWorldConfig. That should help resolve that in your case.

@GodsDead

For the most part I would agree with this, people just don't like change even when it's for the better. The defaults aren't bad either, I've only had to change one or two things. I think CreeperExplosions is exactly backward from what it should be. Villager Trading shouldn't be prohibited outside of claims by default in my opinion. Other than that, defaults seem to be just like 7.7

@Tux2, @BC_Programming

I have just uploaded an extension plugin that adds a mob spawning and mob damage flag to claims. My first plugin, and built it in about an hour or so. WIll refine over time...

GriefPreventionEx

I hope ya'll enjoy!

@BC_Programming

Fair enough. Your arguments to my separate plugins ideas are just. The idea stgram gave sounds cool, it gives more of a sense of modularity while not introducing the problems of running seperate plugins at once. And to the people complaining the setup is too complicated? fk off. You're running a server, not buying an Apple product.

@BC_Programming

My ram stays around 780MB of the 2GB allocated (16GB Total) when using the 7.7 version. It starts at 1GB when I start the server with 7.8 and increases 100MB every minute until my server crashes (16GB).

The database migration from 7.7 -> 7.8 deleted my mysql database because it wanted to migrate an empty flatfile to the mysql database.

The old plugin was good, you made it worse by adding more configuration. 'What would be good:' I don't know if you are familiar with WorldGuard. few years ago it was as simple (still is) as the old griefprevention with just 1 config to control pvp,explosions,... Then it added support for world specific config, but instead of changing the whole plugin they just made it possible to "add" a file with specific world configuration.

The current plugin would be good if the configuration was the same as 7.7, but just for people who wanted to add something extra, they could "add" these settings in the config (or other files).

@BC_Programming

You sure do know how to pose an argument. Or a page of them. I admire your stoicism.

Have you thought about a simple change, to give the masses what they want: In the main config, insert values such as: GlobalSpamProtection: ALLOW GlobalPVPMechanics: ALLOW and so on. If disabled, no further per world settings can enable those. If enabled, everything goes as planned and configured.

Because to me it seems that some people just want to disable that stuff due to incompatibility with plugins or inability to handle 10 separate configs. I personally used copy and paste. That above would equal plugin separation: The idea comes from Essentials, you dont want EssentialsChat? Delete the jar. But a few config values installed as a kill switch would do a perfect job and would acquire you the peace to continue working on this valuable plugin. :)

@Maximvdw

I've had people report this.

I've yet to reproduce it. The 7.7->7.8 migration goes flawlessly every time I do it. I imagine some revisions to the schema might confuse 7.7 if you run the older version again, which could definitely lead to it deleting things, but that would be a result of running the older version with the new data. Otherwise it migrates properly. If you rename the griefprevention.jar file be sure to not give it the jar extension. I personally add .bak because I an unsure if Bukkit will try to add a .zip to the class loader. of course if you have two versions of the same plugin weird stuff is going to happen, and in GP's case deleting information seems like a likely result.

Maybe you shouldn't have -XmX set so high. If you set a high maximum, the server is going to use it because garbage collections simply won't happen until necessary. 7.7 and earlier had innumerable forced garbage collections. That seems like a good idea until one realizes the VM has a much better understanding of when and how a GC should be performed. Also, it was responsible for several investigations into slow server performance with that version which were traced to constant calls to system.gc(), which itself took long enough to delay certain tasks from completing, and could sometimes take enough time that the server quite literally kicked everybody and refused all connections because it was just running the tasks over and over again.

In other words, you want a plugin with only the subset of features you use, and to hell with the people who [i]requested the other features[/i] in the meantime. because, F-them, right? they don't matter, after all. Only what you want is important.

Spam protection can be disabled. PVP Protection can be disabled.

Heck I'd be able to give the benefit of the doubt since the documentation for 7.8 is fairly sparse, but those two settings are documented in the 7.8 documentation page, which itself is clearly linked in the main pages first few paragraphs. Ironically, 7.7 doesn't allow you to disable it's PVP logic at all. 7.7 is the "old version" people are putting on a pedestal, by the way. (there were however some issues with PvP as I recall with 7.8 that were more recently addressed since the beta version was made available).

7.8 cannot inherit settings from 7.7 because in the context of 7.8 7.7's settings make no sense. Some of them either do not exist and even if they did trying to migrate the data would be more work than just changing the settings in one file and renaming the template.

I guess the problem is some people figure they should go through a config line by line, instead of trying the default and making changes as they discover things that need to be changed.

Just look at a 7.7. configuration. The settings have names like "EnderPearlsRequireAccessTrust".

Alright- but what if you want a player to need build trust? Then you're screwed. It's a bunch of hard-coded booleans that were chosen based on what was needed by the previous developer for his server. And that's OK, but what is effectively being said is "I liked the plugin when we couldn't change much" and it simply makes no sense, especially given that there were an equal number of people saying the exact opposite to the plugin developer when it was more restricting, and the respose was effectively, "if you don't like it, fk off".

Was I mistaken to not take this same approach?

yeah, because removing those features that have existed since something like version 7.5 would be a completely simple task that requires no investment of work to do.

Oh, uh, that was sarcasm, by the way. It would be a complete waste of my and anybody elses time. Who would maintain those separate plugins? Oh, us, of course. Because maintaining one is just sooo easy, we need to split it into several and then deal with the innumerable issues and problems that will result. And that doesn't even address the problem of where the settings would come from. If we split the plugin people will just complain that they need to now configure their spam protection via the griefprevention-spam folder, or how they need to change PVP options with griefprevention-pvp, and how they can't use the siege plugin and they get a weird error about PVP, so we have to guide them through the fact that the siege component relies on the PvP component, and try to justify it using some academic bullcrap about how it's "cleaner this way".

Separation of concerns is great, but there is a such thing as overly adhering to academic principles in practice.

Pretty sure those were resolved in a development build once they were reported. If both the attacker and defender are a player and griefprevention.pvp.enabled is set to false, GP doesn't do anything at all. (even if a player is otherwise tagged as PvPimmune). By "nothing" I mean it ignores the event entirely and just returns immediately.

This is only easier in concept. separation of concerns sounds like a gilded cloud of maintaintability but that cloud dissolves pretty quickly once you get experience. In my experience trying to separate them like that would cause more problems because for one there are more plugins to deal with, and who knows what combinations occur. Oh, also, what about dependent plugins? how would dependent plugins using GP figure out which components are being used? they'd have to check manually, or the GP core could somehow check itself. It would only make things easier for people that only want the very core. It makes things a pain in the ass for everybody else. (should each component be in it's own data folder? should it all read from config.yml, and if so, what happens if one of the plugins are removed, how do we keep the data from that plugin in the config? (answer: we can't, not easily). Dependent plugins would become more complex as they have to manually inspect what GP components are installed based on their own features, and there will be plugins that assume certain components exist and any bugs of course will fall on our doorstep. And separating them makes each component more complicated too. Would they be separate projects? If so, who would maintain them? Document them? respond to comments, Tickets? Oh, of course, we would. Right. Because the two hours of demoralization I get from working on the plugin every week is simply not enough.

If you had it for a while, are you referring to 7.7 or 7.8?

GriefPrevention is primarily about preventing Grief. This means that one of it's features happens to be protecting land claims made by players, but that also extends into other features. Anti-spam was added by the original developer because he ran (or runs, I think) a server and wants to run as few plugins as possible. This is also probably why many of the features were added to one plugin, rather than separated into other plugins. A perspective I happen to support, needlessly following some nonsense idea of software 'purity' is something only done by people with no actual industry experience. Wilderness protection has existed since the [i]very first version[/i]. So if you've had it for a while I'm surprised you seem to feel this is some new feature.

it doesn't have rollbacks at all. You must be confusing it with another plugin. Nor does it have "currency exchange" (?) the ability to purchase and sell claim blocks via Vault is present, but I don't see how that would be currency exchange.

Wrong. Each feature you mentioned (well, the ones that actually exist) was added based on request- with the possible exception that some were added by BigScary for his own purposes, and he shared the plugin to allow others to use it as well.

I have to echo that sentiment, what with Griefprevention not being solely a land protection plugin nor being particularly time-based. land protection happens to be one of the features it has but is not the primary goal. I can only guess time-based is referring to claim cleanup or something.

I like how you didn't even look at the project page(s) or any actual information to find out who is more active with GP. Given the other parts of what you mentioned both here and in the PM (the one Tux2 actually had to share with me himself...) I'm thinking you either have been using a very old version of the plugin or simply never actually looked into what it did, and suddenly you changed some options and found these new features and decided they were new- and also confused features of other plugins (rollback? What? that's not even a planned feature...) with GP. I can only guess you put the same amount of time into your research of the plugin as you did trying to configure it, which may be one of the causes of the problems you are having.

You are referring to the removal of features that have existed in the plugin pretty much since it's release, years ago. So I think the delicious irony is the people crusading to have the "old plugin back" don't even know anything about the old plugin.

Easy. Fork the plugin and "fix it" yourself. That's what's great about Open Source. In fact, several folks with similar goals have made forks of Tux2's repository, for many reasons.

More fool me for trying to make the plugin more configurable and remove some of the hard-coded capabilities in the plugin.

@Luficer

There is griefprevention.enabled, griefprevention.pvp.enabled, griefprevention.spam.enabled, and griefprevention.siege.enabled settings.

WE want the old plugin back!.. im switching over again to something else. The old plugin was good. This one is junk.. its 100x times harder to configure for doing the same thing, I get lots of memory leaks (16GB ram usage) , the plugin auto deleted my whole griefprevention mysql database after updating, im going to use the old version again...

EDIT: And the same thing the guy under me says