@Possessed45

Yes, you need two set two config options. One to require a permission for creating a custom claim, and one to disable the automatic chest claims.

Yes, if you list your worlds under creative rules worlds in the config, then players will only be able to build in their claims. Because this option is designed for creative mode (not specifically for your scenario), you should look into the details and make sure it's what you want. For example, there's a rule about the number of animals in a claim based on its size, and a rule against resizing claims to make them smaller (but they can be made bigger). One of the biggest problems for a survival server running in creative claims mode is that players could get "trapped" in the wilderness easily, and you'd have to save them unless they have another plugin like /home to help themselves.

@ThisUsernameIsMine

Yeah, the next version will have that fixed, plus a better login/logout notification spam fix, and customizable/translatable messages.

@zedadiaswick

Argh... okay, okay. But ONLY if there's lava or a lot of water in the claim. I'll try to squeeze it into the next release.

@ryvix

Possibly? I'll look into it.

@Ta6akus

I changed like 10 lines, bro, and it's been less than a day since the last release. Give me a break will ya?

@ben3683914

Later, after localizability. Sorry I can't confidently give you an ETA.

@leiger

First, I don't put in features that I think aren't stable. The login message thing was a minor oops, not the usual course for this plugin. Second, if I turn new features off by default, then I won't get good feedback AND I can't automatically turn them back on from my end, so everyone would have to update their configs to opt-into the new features, even though I've updated them to be on by default. Finally, the default should always be maximum anti-grief protection. So far, the only features I've coded but defaulted to off are the eavesdropping and siege features.

@snowy007

Immature players will do whatever they can to cause a problem. You have to close all the holes, so you might as well do it all with one plugin to reduce your headache in configuring and updating.

@Tehyoda

The reason for this rule is to prevent two players from colluding to cheat the system. Here's the scenario. Bob and Jane play on a siege PvP server because they love to pick on other players, but don't want to ever be sieged themselves. So when they log in, they siege each other but don't destroy anything, then go looking for victims. When they leave the area, both their cooldowns start, so now their bases can't be sieged by their enemies. So now if they see anybody who could actually beat them, they can run back into their bases and be safe, at least long enough to end their PvP timers and log out safely.

More enemies = more problems. Just like money. :) Players can stay in their houses and wait for bad guys to leave, build a secret exit, build traps to kill those hanging around outside, call for other players to help, use the anti-spawn-camp feature to just walk right past them... etc etc. The point of siege mode is that you can be sieged. If there were any way for a player to get out of being sieged without risking something, then that would be a bug.

Players who want the option to sit out PvP whenever they're feeling vulnerable should not play on a siege mode server. They can go play Factions, or a non-PvP server.

@Feaelin

That option is for ALL claims to expire. The timer for newbie claims to expire isn't configurable. I think it's 10 days.

@ben3683914

What permissions are you wanting?

@Bigscary: Is "IdleLimitDays" the number of days a player (with only a "first chest" claim) can be inactive before the "first chest" claim is deleted?

A player should only be able to be sieged once an hour, along with only being able to use the /siege command every hour. So multiple players can't repeatedly siege a player. Also, anyone got any solutions to keep people from camping outside players claim locations and killing them every chance they get?

@bigscary

I understand why you have implemented the delayed join/leave messages, and agree with your intentions. However, the way it currently works isn't really as good as should be expected for a plugin this far into development.

May I suggest that all new features (including this one) be disabled by default and can be enabled by a config option? Once the feature is stable, the config option could be left there, but the feature would then be enabled by default instead.

Doing this would add a little bit of additional work when adding features, but it would mean that users of the plugin have more control over what they can do and therefore the plugin can be adapted to work in more situations.

Thanks, leiger

@Possessed45

we dont do wilderness protection, the style of protection you are asking for is more like the creative world mode of GP

Is it somehow possible to stop people from changing other peoples musical note blocks?

@bigscary

Nice work! It's great that you take optimising your plugin for performance so seriously.

Alright, glad to hear you've got a plan to rework the login spam feature.

I don't question the removal of lava when unclaiming land, just want more steps to ensure players are aware of the consequences of unclaiming. Most other features of protecting land is simple common sense stuff, players can safely guess that claiming land protects them from block destruction, and containers would be protected too. They can guess that using /trust would give another player complete access to their claim, and the hazards that could bring. They can guess that using /abandonclaim would allow others to edit their builds, even potentially level it. I doubt anyone would expect it to remove anything inside the claim, that is a strange concept of a protection plugin; almost akin to automatic griefing, before someone else can get to it. Again, I don't really question the removal as a feature. I just feel it needs clear explanation, as it is quite a dangerous feature to overlook.

Hey guys! 4.4 will be out today with LOTS of performance enhancements. Hold onto your seats... the numbers are in... and the CPU cost of running GriefPrevention has been cut in half! If you care for the details, read on...

After profiling, I discovered that GP was spending 83% of its time handling water and lava flow. I managed to reduce the cost of that handling by 80%. Breaking blocks accounted for 5%, and its cost has been reduced by 19%. Placing blocks accounted for 2% of all effort, and the cost of processing that has been reduced by 50%.

By the way, on my machine, I see that GP is 80% cheaper to run than NoCheat. So put that in your brainbank. Since NoCheat is generally regarded as both essential and lean, this fact reflects very favorably on GriefPrevention.

@bazookapooka

Well-made block change logging plugins are CPU-cheaper than preventative plugins, but require you to constantly investigate and roll back grief. I've heard that LWC is costly because players tend to have a LOT of protected blocks, but I dont think you'll ever have an apples-to-apples comparison of any two anti grief plugins, because if they do the same thing, you won't find them both installed on the same real server anywhere. However I can tell you this - GriefPrevention will protect your players MUCH better than LWC can alone. Not only does it protect an area rather than individual blocks, but it also covers lots of other types of grief like spam, spawn camping, fire, and wilderness destruction.

@zedadiaswick

I'm going to fix this login weirdness by changing the feature entirely. Just hang in there. :)

As for lava, well... why would you unclaim something if you care about the stuff in the claim? Remind your players that they can resize claims. They don't have to delete and recreate them. The lava rule is extremely important, because without it, griefers could claim land, dump lots of lava, then unclaim to let that lava spill out all over the wilderness. I understand there will be some rare cases where a player will unclaim an area to let his friend claim it, but still more rarely will there by lots of water and lava above the sea level in that area. Remember, playres can just /trust and/or /permissiontrust their friends. The ONLY benefits of actually unclaiming and reclaiming are that the new owner can resize the claim and use /permissiontrust.

@shutka

If you have any actionable information, please share. For example, how do you create two claims which overlap?

Also, any plugin can cause lag on a server that doesn't have enough power. This one does an extremely good job of delivering enormous value without enormous CPU cost. If you can tell me a configuration where GP can't run on a reasonably equipped server with a reasonable plugin load, then I will be happy to investigate.

You're very rude. Please don't post again unless you have something helpful to say.

@bigscary

I have a suggestion for the new delayed login message; could the initial login have no delay associated with it? Or maybe all logins should have no delay, then just make it so the login message can only be shown following the delayed logout message being shown?

My players seem to be taking messages being shown before the login message as an indication of poor connection issues. Most of my players say their hello immediately when joining, so I see that issue quite a lot.

Also, I think I remember you saying that lava would be removed when a claim is abandoned? I've just spotted someone complaining that their lava has disappeared from the console. I think if removing claims is going to cause changes to the world, there needs to be a warning system. It needs to ask them if they understand and are okay with the changes which will take place. I think some players sometimes just remove a claim and re-do it, instead of resizing. Or they'll remove their claim so a friend can claim it instead.

is this more lightweight than having logblock + lwc? i host a small server with normally 10 players on , just wondering if this is a lot more lightweight than what i currently use. because when players start traveling far then my logblock queue gets big

@shutka

to the creator's defense, I have seen you talk trash several times here without a single line of proof, logs, help requests or anything similar... so I guess you're not quite ready to put your money where your mouth is, to say it politely

@AuntieBeast

Mine has more than 600 claims. Max player count is 20 with 1GB of RAM (that's the recommended ratio on the bukkit wiki). Of those 600 claims, there are 200 unique owners. For performance, the size of the claims shouldn't matter, only the total count.

Hey guys I started to notice some lag on my test server yesterday. Since I haven't made any enormous changes to GP in the last few days, it could be just a problem with my hosting provider and not my code. But just in case, I did some plugin profiling, and I identified many opportunities for performance improvements. I'll run those improvements on my server for the next day or so, then when I have the numbers, I'll publish those metrics along with the new version of GP.

I'm putting off the localizability thing until I get these performance improvements done.

@rourke750

No, it's just in the logs. I could send it to all ops online, I suppose. :)

@stgram

Given that you're running so many other plugins, GP might have just been the one plugin to push you over the edge. At least temporarily while you migrate over to the new plugin, you might want more memory or less max players. I think that overall, you'll find GP to be less expensive than Residence when all the migration is done, because GP does ONLY anti-grief and aggressively caches information more than Residence does, to prevent re-doing work. Also by adding GP, you might be able to eliminate some other plugins, for example anti-spam plugins (NoCheat has anti spam which can be disabled in its config, by the way), fire-controlling plugins, anti-tnt and explosion control plugins, etc.