GriefPrevention- Community Input

Thanks :)

1. That's a good one, I know that Villagers are susceptible to damage from Zombies/Monsters in admin claims, but I didn't even know they would be invincible otherwise. I'll probably make this an option (GriefPrevention.ZombieSiegeDamageinClaims)? I can imagine other plugins like GriefPreventionFlags adding more specific functionality. (It might already, in fact)

2. Actually, it's fully possible to see who is doing the trampling. Again: great little change, easy to do but adds polish- exactly the type of feedback I'm looking for :). GriefPrevention.Claims.Trample = [true|false] perhaps? Could even expand that to allow configuration of what can trample crops; maybe players can't, but monsters and animals can? etc. Seems like overkill for such a simple feature but my thought process is to simply give admins the tools they need to get the functionality they want, rather than try to dictate through the plugin how they "should" run their server, type thing. There is already a setting for creatures, but seems like an ideal option to expand.

3. Funny you mention this, actually, when I was refactoring and saw the current CooldownHours setting I thought to myself "why only allow it to be set by the hour?". For breaking configs, I actually have no problem with it if we get some improved functionality, and I'm basically breaking all the configuration options for 7.8 anyway since they are becoming world specific configurations (eg. not in config.yml). Perhaps the cooldown option could simply be changed to minutes instead of hours? That could work. Being able to relog to use trapped I'm going to class as a bug and look into though, Thanks for that tidbit!

4. I've partly addressed this in my recent work, due to some similar notes about how annoying it is. It is now possible to disable it completely so it never shows, or to configure the number of blocks between when the message is shown. The permission node idea is interesting too, and could be useful.

5. I fixed the shearing, but didn't even know about the other two- definitely a todo before the next release :)

For the configuration folder, I noticed that as well. Actually, come to think of it, changing it for the next release makes a lot of sense since a lot of the configuration data will be changed to support world-specific configuration. Obviously the existing folder can be renamed or copied to a GriefPrevention folder.

Like I say, I have no qualms about breaking compatibility with older stuff if it adds useful features. The one thing I'm careful for is of course compatibility with other Plugins that hook into GP. Of course, it's best not to break config's for no good reason, but I don't like keeping silly configurations around for compatibility purposes because it just makes everything a big mess; best to break it once and clean house rather than have to explain why options don't do anything or don't make sense.

THANK YOU very much for your feedback, I really do appreciate it :)

Also not all servers have sea level at the same height. Some terrain dash control servers including mine, have to love the way to type of as well as 32.

That's an interesting idea. The best I can think of is to have a GriefPrevention.Ranges setting that contains named Ranges, for example:

GriefPrevention
    Ranges
      Above50:
        LowerLimit:50
        UpperLimit:256
      Below50:
        LowerLimit:0
        UpperLimit:49

And then the range names could be used in some way with the current permissions; eg. perhaps each group can have a set of wilderness/claim options for each range group.

I think that really complicates the configuration though, having it get range information from elsewhere. But it's an interesting idea.

When a player says things asking about how to claim, they are already given a brief information packet. You can configure the messages in Messages.yml, as well as the Regular Expression. By default it shows the message to players when they say anything containing the word how and claim, protect, or lock. By default it links to a youtube video created by the original Author of the plugin. You can change Messages.yml entries 'SurvivalBasicsDemoAdvertisement' and 'CreativeBasicsDemoAdvertisement' So you can automate your response by changing this message to tell them to use a golden shovel to claim.

The coalescing feature is an interesting one (where you can create a claim 'around' one of your existing claims to resize it). I will probably only allow claims to become bigger- that is, all the originally claimed blocks will still be claimed) to avoid any weird corner cases.

When a player puts down their first chest it emits another message: "To claim more land, you need a golden shovel. When you equip one, you'll get more information."

(Again, this is configurable); when you equip the golden shovel it shows you the whole claim spiel, and when you create the claim it tells you how to use trust. What you're suggesting is sort of a "Help framework" which is quite a good idea anyway. Then the default messages can be changed to refer to new help commands as well, for more info.

A command to give full trust to a player. I guess they way you do it now is /trust player, /accesstrust player, and /containertrust player. Would be nice to have just 1 command to do all that, maybe /fulltrust player, or similar.

Actually, /trust does this already- access, container, and build trust aren't really separate, but rather 'levels' of permission. If you have build trust (given by /trust) you get container and access trust as well, and if you get container trust (containertrust) you are given access trust as well.

I added a few minor things for spam protection, But some were already there. change the message, change whether spam offenders are banned, change the death message cooldown (to prevent death message spam from a single player), same for login, and (more recently) I changed it so the kick and ban functions can be set to instead run a server command (for example if there is some sort of other plugin command that people want to perform), which default to the vanilla commands (ban bans and kicks the player). Not sure what you might be looking for on top of that.

transferclaim: I'll probably give it a separate perm and also allow an optional second arg to allow for transferring from one player to another. Almost certainly with separate perms. Transfer between two arbitrary players will probably fall under adminclaims, while the previous functionality will be a transferclaims perm of some sort.

Re McMMO: I'm actually not even 100% sure if that could be stopped even using the mcMMO API, seems like either GP is getting the event after McMMO (after it applies,say, bleed) or mcMMO is not ignoring already cancelled events. I'd say the former is more likely. I will probably see if I can workaround that somehow, possibly by cancelling any added bleed effect on the entity or something. If McMMO is ignoring GP's attempts to cancel the event, I think I can use plugin.yml to specify that GP load After mcMMO so GP get's the event after, too. Will definitely make an effort to look into this.

One thing I don't really like about the new configuration setup is that the features seem to be getting more and more vanilla specific. Before, it seemed that GriefPrevention kind of met in the middle with vanilla and modding, but now, other than the better Mystcraft support, you seem to be drifting away from that a bit.

Well, so far I've just moved already present configurations and added a few others. It's notable that, unlike some other plugins/mods which officially support things like BukkitForge and MCPC, the fact that GP works at all is almost coincidental; or, to be more precise, we generally have no interest in reaching outside of the bukkit API to fix issues that are specific to Mods or mod packs. If it can be fixed within it- such as with the explodableIDs and other mod-specific bits of configuration data, then we'll be game to give it a go.

However, some issues just can't be fixed without adding very special support for modded servers. For example there is no way of detecting Thaumcraft wand usage and preventing it in claims without making GP a server-side Forge mod. And I won't mention my feelings about using Forge for development in order to keep this thread civil :P. Fundamentally it's a case of the adapter API not raising events to GP, for whatever reason. IMO that's a case of the implementation of the Bukkit API failing more than a failing of GP. Maybe it's related to how Thaumcraft breaks the blocks, I don't know.

One of the biggest reasons I wouldn't add anything "mod specific" is because that would mean testing it; so I'd have to test it both on my a bukkit server (make sure it doesn't break vanilla) as well as an FTB server; and in order to run it there I would need to basically backport to 1.4.7. I have no interest in backporting, and I'm not really a fan of using mods very often, so it would just be a lot of work for something that I won't be able to fully test and simply don't "feel", if that makes sense.

of course if it's possible to add support for features in a modpack through standard bukkit API features, I will definitely think about it- things like being able to set explodable blocks and whatnot. But any feature that requires "reaching past" the bukkit API (eg. making a Forge Server mod or something) is simply not going to be in the scope of the project (unless there is some easier way of doing it that I don't know about). The best I can think of would be to actually create a Forge "mod" file inside the Jar that delegates to the Bukkit version, but I don't think that's a particularly simple task.

That all said, I am curious what sort of Modpack-specific configuration options you are thinking of and what changes I've made recently that are vanilla-specific? (I'm not being confrontational, I'm actually curious, perhaps I can fix them)

Again I don't want to come across as negative here, Just that since I don't actually play Modded Minecraft very often, and never play Modded Multiplayer, I really wouldn't have any idea what you mean by Mod Support. If it's something possible without making a special Forge Server Mod, I could look into it though.

That's actually a great idea! I guess I took a shortcut and went with a boolean :P, never really considered that it could be ambiguous, but now I see that it could.

For the spam, glancing at it now, it has a lot of hard-coded length and timeout settings that are ripe for moving to the configuration file. One interesting side effect of cfg's being per-world is that different worlds can have different spam settings, which could be useful.

Siege mode is more geared for PvP servers, of course, but those are some interesting feature ideas for it.

For the expansion, with the exception of certain blocks, GP will give a message such as "other players can undo your work here! Consider creating a claim or expanding an existing one". The automatic resize is tantalizing, but would require careful work to make it useful. My thought on that is perhaps a configurable "range" and if the placed block is not a "trash" block and within X blocks of one of their claims, and they have more than a configurable minimum claim blocks, it will automatically expand to include the area (with of course a message saying as much). Of it's outside the range or they are below that minimum, it will do what it does now (warn about other players being able to undo), which seems like a useful middle ground. Most players probably expand outside of their claims one block at a time while building a wall, roof, or floor, so it ought to cover the more common cases, and a configurable minimum claim blocks. Though I'm still thinking it could be annoying if you want to build something just outside a claim, but not expand it, though.

Would also love to get individual settings/capabilities for all the eggs and dispensers. Straight from the extra plugin (which is also nice, but a lot more limited, barely use any of it) that I have to use in addition to GP:

EggBlocking: true Eggs: CreeperEggBlocking: true OcelotEggBlocking: false SkeletonEggBlocking: true SpiderEggBlocking: true GiantEggBlocking: true ZombieEggBlocking: true SlimeEggBlocking: true GhastEggBlocking: true ZombiePigmanEggBlocking: true EnderManEggBlocking: true CaveSpiderEggBlocking: true SilverFishEggBlocking: true BlazeEggBlocking: true MagmaCubeEggBlocking: true EnderDragonEggBlocking: true PigEggBlocking: false SheepEggBlocking: false CowEggBlocking: false ChickenSpawnEggBlocking: false NormalChickenEggBlocking: true SquidEggBlocking: false WolfEggBlocking: false MooshroomEggBlocking: false SnowGolemEggBlocking: true VillagerEggBlocking: false XPBottleBlocking: true Dispenser: MonsterEggsDispenseBlocking: true XPBottleDispenseBlocking: true FireChargeDispenseBlocking: false WaterDispenseBlocking: false LavaDispenseBlocking: false

Also it might be a good idea to just have configurable options lists (like container trust) of items/blocks that a player is blacklisted/whitelisted to place/use. Make them wilderness + inside/outside claims and we have a very configurable system that I would be hard pressed to work out with either modifyworld, worldguard or other control plugins (and I don't know of any others that do that really well).

1. That will probably not happen. If anything, it will just allow the use of /gp and simply toss whatever else is passed back as a command itself (eg /gp Trust would act the same as /Trust). I've added a simple /gphelp command which provides a bit of background to players on Claiming and Trusting. I imagine /gp without arguments could show a summary list of all commands.

2. I've been adding a few useful admin-type commands. things like /claiminfo which actually provides the claim ID, number of subclaims, etc. As well as the capability to abandon all the claims of another player (if you have perms to do so, of course) in all worlds or a given world, remove all claims in a world, etc.

3. I can see that- Only issue I see is that a name change would disassociate the world.

4. Yep, that's on the table as well. I was thinking I'd make the cooldown in minutes instead of hours, and a cooldown of 0 would disable using /trapped entirely (as well as the information shown in chat when somebody says the magic words)

5. Perhaps WildernessContainers and WildernessAccess values which allow or disallow the use of containers and buttons/levers respectively in the wild. There is the issue that a player could stumble on a container and simply create a claim around it, though.

6. The implemented Database support is quite weird. It doesn't have a Primary key and in some ways just seems to use a text format that only coincidentally gets saved to a DB. The issue is that at this point, the current Schema is being used, so the only "workaround" would be to implement an entirely separate Database Datastore that uses a different schema, while keeping the other one around for compat reasons. Definitely doable. That said, it already should work with MySQL (Which I believe means it would work with MariaDB as well) and PostGreSQL (That was a Pull request by a helpful user). I was considering adding support for SQL Server but I doubt it would get very much use.

7. This is a repeated sore point for me. First we have the problem that a lot of bugs and issues are actually because the API isn't passing GP the appropriate events (eg. Thaumcraft Wands, just as an example), which could only be fixed by making an actual Server Mod specifically for Forge, which is simply not going to happen (and if it does, it almost certainly won't be me) Another is that the extra IDs can shift between Modpack versions as they add or remove mods. I don't play Modded Servers at all, and I play FTB only a few days at a stretch, so exactly what items elements would need to be added to certain GP Logic isn't something that comes up. I'd certainly consider adding proposed lists of items for the customizable sections to the default config, but there is also the concern of trying not to prefer one modpack over another, I think.

For siege, I've mostly been trying to address some of the issues I've personally encountered. For example in one instance I was mining and used /bed to return to my base; it bugged out and put me in a wall, as it would do, but apparently somebody was also sieging me and so I couldn't break the block that was suffocating me and died... and every single item I had went to the attacker. Frustrating. Not really the siege functionalities fault, but still annoying. Most of the ideas on it I've gotten from comments on the bukkit page or in this thread. One of the issues I also had on the server was that I would often be sieged by multiple players, in such a way that I would be sieged, and either kill the attacker or defender and within a second be sieged again by another player, which was frustrating. I've been trying to think of a way to balance it, by perhaps giving the Defender an advantage based on how many are in the claim when it get's sieged, so if more than one player decides to team up to fight somebody they will have to work together even against that one player. Another idea is to require all the other players (rather than the owner and the sieger) on a claim to list as either Attackers or Defenders before a siege actually starts, and then they could be balanced with buffs to try to make sure the Defenders have a chance of fending off Attacking forces, and players that don't choose a side are ejected from the claim. On the other hand that's getting into some fairly involved functionality, too. Another of the big things that discourages it from being enabled is that the damage is permanent, so I was thinking of making it so that, as another user here said, the damage would be "healed" when the siege was over. This could be neat if during a siege, as it would be possible to allow all blocks to be broken by the attacker, and the only thing protected was containers; An attacker could lay waste to a base but once the attacker or defender died it was like it never happened, sort of like a 'minigame' if that makes sense. Perhaps even configure it so that both participants are rewarded, eg rather than being able to loot their stuff, they get, say, claim blocks or something else (probably facilitated by running a common for the winner and loser). That would encourage it somewhat by both parties, and make it "PvE friendly", and in PvP worlds it would encourage both to try to fight outside of any claims.