@BC_Programming

Lol BC, if you have trouble resisting the urge to keep adding new ideas you think of, then you might try another approach in the future. On my projects, I decide what features (including tickets) will be added to a build before I start on the build. The upside is you always know what is coming, what needs to be done and what needs to be documented, it also keeps your ETA's (whether internal or made public) more succinct and accurate. The downside is that any feature requested today will be guaranteed to not be in the next release build, no matter how awesome it might be. Of course bugs are fixed as fast as I can eliminate them and don't follow this rule.

@BC_Programming

@Roenie82

The idea was to finish this BlockOverrides capability and integrate the trashblocks into an override rule instead of a set of kind of weird options, make the permissions more consistent (eg. no doubles, change defaults), and that was it, at least code-wise. I wasn't expecting the Block Overrides to take this long but they've been giving me trouble. Heck I'm working on it right now and it's 4AM and I have to work tomorrow :P

Once that's done hopefully I can build a version and upload it to the project page, at least as a Beta, and then while that is under review for approval try to update the appropriate documentation before it is approved.

You are entirely right. I wanted to "feature freeze" right after I made world configs... then I got the idea for Rules... then I got more ideas for new rules... etc etc. Problem is that a lot of comments make light of issues that could be fixed or awesome feature ideas. Heck BigScary himself posted some enhancement ideas which were pretty epic and got added in the very next dev builds (/softmute and /ignore commands). So people need to stop coming up with awesome ideas :P.

Hopefully I can at least get a Beta out before a Bukkit API implementation for 1.7.2 drops, if only so, as Tigergruppe said, people know it's still alive and being updated. April was hella-long ago.

@Tigergruppe

The difference is that if I call a release "stable" I'm going to make damn sure it's stable and documented. Too many plugins release a "stable" version and then have to scramble to fix bugs that corrupt worlds or destroy data... that is, the plugin was not at all stable. They just called it that. IMO that's outright lying, regardless of any good intentions.

I could easily call any development version stable according to some of the same standards some other plugins might call theirs "stable". That standard seems to in some cases be "it compiles". More importantly before I actually upload any "promoted" build I would need to update or change both the main page and all documentation. Even the 7.8 dev documentation is a few builds out of date at this point.

Also, with your new versions, should we expect permissions to act as they are? Everything has been changed around and there is now a True/False style of option for every little detail. Will the per world options be able to be toggle-able? For example, some sort of master config that blankets over all worlds and not just one?

the 7.8 dev build documentation is available in the pages section. It's a few builds out of date but still applicable. Off the top of my head, for buyclaim you would need griefprevention.claimblocks.buy (changed from, griefprevention.claimblocksbuy or griefprevention.buyclaimblocks or whatever it was before) as well as griefprevention.commands.buyclaimblocks; and the equivalent permissions with sell in place of buy for selling claim blocks.

This looks like a case of a permission(s) that should be set on as the default, methinks. Some of the perms seem redundant- in this case we have both griefprevention.commands.buyclaimblocks as well as griefprevention.claimblocks.buy. This redundancy is because there are often two permissions for what appears to be the same thing: one for the actual command being issued, and another for the operation itself. In this case the redundancy is probably something that can be eliminated, since it's unlikely there is ever going to be some way of selling or buying claim blocks without a command. But for some things such as editing claims, changing claims, etc. I can imagine there being ways of doing the same thing both with a command as well as interactively, and it may be desirable to control them separately.

The reason the permissions were changed was because I got a lot of requests to change them. Not counting the "The permissions make no sense" comments and PMs. Evidently some redundancies have crept in particularly from permissions that used to control a command still existing and being required but not having any observable effect beyond the equivalent griefprevention.commands.<command> permission for that command (eg. the buy and sell claim blocks commands). I'll have to remove those as needed before any release. There are also some configuration options that have functional overlaps that need to be rethought.

Docs are the part that will delay any release the most. Partly because there is so much to document but also because in the process of such documentation I often find there are things that could do with a change or revision, then have to practically start over again with the documentation to include that particular change. That and the old documentation for 7.7 and earlier needs to be there somewhere for those using older versions.

The development doc mentioned above, in the pages section covers this. There is a "SingleWorld" mode which can be set to specify a single name. For example, if this is set to "world" than world.yml in WorldConfigs will be used as the config for every world. It's also possible to set a template world that will be used as the default for any new world. If memory serves this defaults to _template.yml by default. (which doesn't exist normally and therefore built-in default values are used instead).

If you want essentially, a "7.7 updated for 1.6.4" I believe there are forks of Tux2's GriefPrevention repository which might add those features. From what I can tell they re-work the external API so no external GP plugins will work, so that could be a concern. Some of them remove features from GP that the author didn't like, as well.

@Tigergruppe

There is no ETA.

And there isn't even a dev build of bukkit for 1.7.2 so I don't know how anybody can possibly expect anything build for that.

I've gone through this already. Do you want me to add the current dev version as a beta or release version of the project? Because I could. Nobody would be happy with it, however, and I would end up needing to release a new version anyway.

There is more to any new version release than the change of what API is being built against, which would be why this one appears to be taking longer than previous versions. And there is no ETA because there is no consistency to when I can actually work on it.

If I recall he also didn't make development builds available, so doing so was more important. and there was far less new code and logic being added than there will be between 7.7 and 7.8. (eg. each version really just updated to support the new features of the Minecraft version).

let me ask you this, though: Aside from being able to download from bukkit.org, what difference will having it available here make? Not much. It will just be a promoted development build. Not to mention all the docs will need revision to account for changed or added features.

@Jsight

And what version is the "Correct" version that you are using?

@Roenie82

OK, I just wanted, to be clear that we/I am more looking for something that will most likely include what you are looking for as part of it's more extensive capabilities.

I was thinking the trash blocks setting could be "auto-translated" into the override framework. Really it could be a single node; more nodes could be added for whatever else was desired as well, including changing permission levels for certain block placement, which could be useful on modded servers; or for example if a server wanted to make it so a player could only place furnaces inside a claim or letting a siege attacker place Levers or something.

@Roenie82

My postulation was that only the owner of a claim could place obsidian blocks inside that claim. I don't see how that example could be interpreted in that fashion; it seems to simply be exactly the same as simply having ClaimControl set to RequireOwner for BlockPlacement. I mean, technically, yes, with that config, only a claim owner would be able to place obsidian blocks inside a claim, but it would also prevent players with build access from placing any block at all as well.

Then IMO it's useless. It means these settings only apply to the wilderness section, and wouldn't have much use at all within the claims section. If no Exceptions or "allow" override claimcontrol, than if ClaimControl is anything other than None or Disabled the nodes are useless.

@Roenie82

The BlockPlacement and BlockBreaking are Rules because they quite literally are rules in the code. Everything added to them will be possible with every single rule as a result and would need to have some meaning in those cases as well. I want "exceptions" to be very 'aware' of Claims and claim permissions. For example, imagine if you want to only allow the owner of a claim to place obsidian in that claim. That's not possible with the "Exceptions" way, which basically just inverts whatever the existing setting is, yet the same configuration logic being used to deal with Exceptional behaviour during a siege can easily apply in a more general case, and apply at all times.

@lolitsthad

That is working as intended. Here's a question though to explain why.

let's imagine it magically removed claims.

Which claims would get removed? the most recently made ones? On what basis would that selection be made? Imagine a player is given that bonus, and they start playing. They make their first claim with that bonus, and continue playing- making claims in a few other places. Let's say their last claim is 500x500 blocks. The initial bonus they got was 500 blocks, but that's removed. Now they have negative claim blocks. What claim get's removed and how is what claim would be removed determined? It cannot remove the last claim- that is using 2500 claim blocks, far more than the amount needed to bring their claim blocks into the black. Does it try to solve the knapsack problem and basically find the closest set of claims that will bring them into the black for claim blocks? What if one of those claims is important? etc.

The way it is now the player simply has to wait until they accrue or are given blocks that brings them above zero. Thus you can consider that received amount an early credit that they now have to pay off.

@ThisUsernameIsMine

I can't recall the specific problem you had that you mentioned, but I'm guessing it was the one involving how createclaims was being used with the shovel. This was a mistake- the Claim tool was checking the wrong permission. That was fixed. Sign EavesDropping was changed to both reset the colour per-line as well as display the location in the world the sign was being placed.

@Luficer

All Datastore's will store any config information in dataconfig.yml. Right now there is a MySQL and a flatFile datastore implementation. the SQL stores stuff such as host, password, user, database, etc. connection information. the flatfile data store has no special information so that is empty.

I'm using MySQL on my test server at the moment but since you are having the issues with the flat file data store I will swap it and see if I can replicate the problems then.

@BC_Programming

What is the dataconfig.yml supposed to have in it? Mine only generated with "flat: {}" in it. The other files look to have generated, although being new to this config setup, i'm not sure what is supposed to be there. Pastebin of the config: http://pastebin.com/cBap478t

@Luficer

The only way those lines would throw that exception would be if the Configuration wasn't initialized. That only happens if the Plugin fails to load properly.

@Roenie82

Except what does "override" mean? What is it overriding? eg when you "override" wilderness Above Sea level, what does it mean? Only thing I can figure is it would mean the opposite.

BlockPlacement:
      Wilderness:
        AboveSeaLevel: Deny
          Override: [BLOCKA,BLOCKB]
        BelowSeaLevel: Allow
          Override: [BLOCKX,BLOCKY]
        SeaLevel: '-1'
      Claims:
        AboveSeaLevel: Allow
          Override: [BLOCK1,BLOCK7]
        BelowSeaLevel: Deny
          Override: [BLOCK9]
        SeaLevel: '-1'
        ClaimControl: RequireBuild

eg: wtf would this mean? Why does the override suddenly take on a completely different semantic meaning based on whether it was override or deny?

This also would mean keeping everything I already have- since despite what you said what I already have actually has more flexibility- It's used to allow siege attackers to place TNT during a Siege if they are the attacker, as well as break blocks in that same circumstance. That is now handled (internally) by the aforementioned Block Rules override.