I've continued the Real Estate addon to work with all the new versions of GP.

I am trying to match my characters in danish, where 3 more letters are present. They do not quite show up as intended, but only close. It looks like german letter formatting. So question is, which format is the messages.yml working with?

I just noticed: running 7.7, people can shear mooshrooms in claims.

EDIT: I was placing a trapped chest instead of a normal one...ugh. And secondly, the sign whisper...how do I turn this thing off? All my admins see it, and it is annoying...

@jbanto

I never said anything about professionalism, but "Professional" means "get's paid to do it". I don't get paid to work on GriefPrevention, this, no professionalism necessary. Further still I've found that when somebody tries to pull out the "Professionalism" card, they are saying "you shouldn't respond to my passive aggressive personal attacks on your integrity as a developer so strongly." often because, to their surprise, I respond in kind.

Tux2 is bukkitdev staff.... though that notwithstanding, since they would get some other staff member to review it, The codebase upon which each development build is created is freely available on github for review by anybody who would wish to. And of course it can be forked and changed if necessary. Jenkins builds are created directly from that github repository. If you don't trust development builds than you can simply not use them :)

I would like to know how to use my expiration I put just right and will not which version works? and by another version if I will lose the land? pq current versions have the folder worldconfigs my not

@BC_Programming

Hey, thanks for all your hard work on this great plugin! I have had very few griefing incidents since I installed it. When you get the chance, could you check out my PR on GitHub?

Thanks and keep up the good work!

@jbanto

Are you ever planning on becoming a reasonably decent human being, or should I just get used to dealing with this sort of abuse for working on Open Source Projects in my spare time? I don't even have to deal with that sort of nonsense when I'm getting paid, and I'm not about to do it for free either.

Just be glad there is actually somebody still maintaining this project, the fact that I've worked until dawn on GP when I have to work that day, and thus end up simply not sleeping just so users have the option to upgrade to a newer build, and yet have to suffer any messages like this is infuriating. I could have very easily 'released' new versions at certain points. I'm not a strong proponent of the Agile methodology and that would just be a case of rebranding an untested dev build as a release and letting people use it under the supposition that it was actually reasonably well tested, which would be irresponsible.

A "Release" build is not going to have some magic spell on it that makes it more stable. It's just going to be a development build with which I am content and most importantly has fleshed out documentation.

@BC_Programming

Alright, so I created a "_template.yml" file since that's what was in the config alread, and deleted the world configs and after configuring the template, did a /reload. It re-created the world configs, but didn't really seem to adhere to the template, so thought I was doing something weird XD

@Luficer

The template file will be used to setup world configurations that don't exist. eg, if you have a world.yml and create a template.yml (and of course set that as the template in config.yml) then new configurations will use template.yml to begin with. If a configuration already exists for a world the template file won't be used.

Ironically the Emerald Blocks being used for administrator claim visualizations was added entirely so I could figure out an issue whereby admin claims magically started to belong to a fictitious "administrator" player, instead of actually being admin claims. I left it in because it's just plain useful to be able to tell the difference at a glance.

@BC_Programming

Ah, well now that it's not spamming my console and I've configured it a bit, it works well. My only other grief is that that template option in the config may not do what I think. I was assuming it'd copy that template file to newly found world configs, and unless it doesn't or I messed it up, didn't quite do that XD If that's worth looking into. Other than that, I do like the emerald borders, kudos! (Hopefully it doesn't blend into grass too much for other textures)

@Luficer Darn, my mistake. So used to being able to see all the methods from inside I forget which ones are public. addClaim() is package-level so not visible outside GP. I will change that for the next build; addClaim() is about a billion times better than createClaim() overall. I'll double-check some of the other methods as well, see what might be reasonable to make public.

You can find the public repository here: https://github.com/Tux2/GriefPrevention

every time a commit is pushed, it is rebuilt and that appears auto-magically as a development build on the jenkins page. That source would be #188. I'm guessing you might have been using a different version after all and the line numbers lining up was just a coincidence. the stack trace says it occured on that line. In each case it was a call to a getter method to retrieve a ClaimBehaviourData (which encapsulates a single rule value). if that returned null, than there would not have been a NPE on that specific line, but later on when the Null value was used.

I do know when I first looked into this issue I could reproduce it, I forget the actual cause but I think it was a mistaken assignment to the wc variable that caused it to be made null. I fixed that, at least I fixed the errors I was able to initially reproduce.

There will likely be a #189 that adds in the completed Rules framework later today when I finish my work for the day. Then it's just a quick scan through the permissions to see if there are any redundancies and then the fun part of writing up some new pages.

I think I've thought out how to do that; Instead of editing the existing pages, I'll instead make new ones with similar topics for 7.8, and of course one to cover the changes between the two, the main page can be moved to "7.7 and Earlier information" and then 'replaced' with an edited version that gives the appropriate overview for 7.8. I think we can safely keep BigScary's original video- a lot has changed internally for more configurability but it typically feels very similar as a player or an op. I might make some new videos covering new features over time as well.

The API isn't really documented; I've added a bunch of events and whatnot, and some stuff is going to need JavaDocs at least. Of Course once I get around to writing 7.8 specific pages I'll cover the changes and additions to the API that have been added as well.

@BC_Programming

I'll try to re-download 188 to make sure I didn't save it elsewhere when I downloaded it. And thanks for letting me know about the addClaim(), I think I missed it when looking for a like method. Not sure where the API would be documented quite yet.

Not sure about wc, but you think the method wc is using could be returning a null and perhaps the line immediately after somehow able to cope with a null value? If you had a public repo with GP on it, I could look, although I'd not nearly be familiar with the code. Good luck at any rate!

-EDIT- I redownloaded 188 and I'm not getting any more errors at any rate! Also, is addClaim() private? I've only looked through the static GriefPrevention methods and the dataStore methods, but addClaim() doesn't show up in Eclipse.

@Luficer

I think What you might find more useful if you don't have an ID and just want to make a new claim from scratch, would be to use the addClaim() method, instead. It takes a claim and essentially adds it to the datastore. just set the id to null on the claim you create, then when you call addClaim() it will generate a new ID and add it to the db store. some of the API methods are "public" but are probably best used internally only, I think createClaim() is one of these, and it's only used twice in the entire codebase (only for creating claims with a shovel...). Strangely, for resizing claims addClaim() is used.

Re the config for data: This is because, in the longer term, the idea is to have a number of implementations of datastores, and then the dataconfig will contain all those settings as well as settings to indicate migration. I'm sure it's possible for every dataStore implementation to be instantiated at startup and then discarded, if only because their constructors should deal with any config saving and loading, but that could cause problems. right now it means at startup both the flat and SQL datastores would be instantiated every startup, which could cause problems. Also if I recall the full URL setting is not required; if it's not specified or is empty, all the other settings will be used. I seem to recall it had something to do with my longer term idea to have different databases explicitly use separate data stores, not to mention (ideally) being able to construct a entirely new datastore that can completely rework the schema without having to worry about old data, as migration can be done generically across any two datastores. (In the future it might make sense once that exists to have a /migrate command, so it can be issued without changing configurations or something).

Line 596: usebehaviour = wc.getOtherExplosionBlockDamageBehaviour();

wc is null; but that is assigned near the start of the method (I just checked for one of those sneaky accidental assignments in an expression), and worse still, the line immediately after that assignment is accessing a method of wc, so by the time the NPE occurs, it should have already occured. Mystery. The other error (with ignition) seems to be the same thing, the only true cause that would point at that line would be if wc was null, but it occurs after a point where that NPE would have occured had it been null.

I'd say you might actually still be running an older version but the lines are different but still match up with the corresponding lines in older builds that caused the same issues for you. I really have no idea why it wouldn't be working for you; (I don't get any exceptions).

Annnyway, I finally got the block overrides working. Technically they worked just fine, it was adjusting them to properly read and write to the configuration that was causing me trouble.

Here is what the override sections appear like. I only have two; they let TNT be placed and destroyed in a claim by the Attacker during a siege (currently the only default), but I added in a option in this example that simply allows players to place wooden planks inside anybody's claim (but not break them). No particularly good reason for that config except for testing. This appears within the "rules" section.

    BreakOverrides:
      TNT:
        Materials:
        - TNT:*:TNT
        Name: TNT
        Wilderness:
          AboveSeaLevel: Deny
          BelowSeaLevel: Deny
        Claims:
          AboveSeaLevel: Allow
          BelowSeaLevel: Allow
          SiegeAttacker: Allow
          SiegeDefender: Deny
          ClaimControl: RequireBuild
    PlaceOverrides:
      TNT:
        Materials:
        - TNT:*:TNT
        Name: TNT
        Wilderness:
          AboveSeaLevel: Deny
          BelowSeaLevel: Deny
        Claims:
          AboveSeaLevel: Allow
          BelowSeaLevel: Allow
          SiegeAttacker: Allow
          SiegeDefender: Deny
          ClaimControl: RequireBuild
      PLANKS:
        Materials:
        - WOOD:*:WOOD
        Name: PLANKS
        Wilderness:
          AboveSeaLevel: Deny
          BelowSeaLevel: Deny
        Claims:
          AboveSeaLevel: Force_Allow
          BelowSeaLevel: Allow
          SiegeAttacker: Allow
          SiegeDefender: Deny
          ClaimControl: RequireNone

Now what I need to do is change the trashblock configuration to be a section within the Place and Break Overrides, and remove the existing trash block configuration information. (I can do this 'safely' because technically the last release version didn't even have configurable trash blocks). These overrides work irrespective of the "nosurvivalbuilding" rule, so toggling that rule would also require toggling the setting in the trashblocks override(s).

Basically the override is checked first- if an entry exists for the block being placed or broken, than that behaviour information is evaluated on the spot.

I'm not 100% sure if trashblocks will fit into this particular scenario. There have been mentions that as it is it doesn't appear to work properly, but the way the trashblocks rule get's invoked is a bit strange; when nosurvivalbuildingoutsideclaims is true, it's used to determine when to allow the block to be placed; when it's not set, it's used to determine when to allow the warning message you usually get to be "denied".

@BC_Programming

Ah, I think I'll look into it again then. In retrospect, hope you have an overloaded method that doesn't require the claim ID, found that rather frustrating @.@ And thanks!

Also, I took a moment to switch my GP over to mysql rather than flatfile, and noticed a few things. Firstly, the mysql settings don't seem to appear until you change the config.yml over to use mysql, which debatably could be frustrating (thinking the file mis-generated or such), and secondly, the Host and Database settings seem a bit redundant on top of the URL. Personally I'd prefer not having the URL option and just have the plugin construct it from the Host & Database options. Lastly, as it migrated data to the database, noticed a slight grammar thing:

"[GriefPrevention] There appears to be some data on the hard drive. Migrating those data to the database..."

The "those" just sounds a bit strange. "Migrating data to the database..." might sound a bit better if you care to bother with such menial things XD

Aaaaaannnnd, because murphy's law, the plugin (build #188) still doesn't like explosion / ignite events. Same error by the looks, but I'll paste it for ya regardless: http://pastebin.com/KvmB6i5A

Thanks again, sorry if I'm harrassing ya too much.

@Luficer

To my recollection I've only added new overloads for createClaim, but that was quite a while ago, when I first added the API events for claims.

Basically it should be stable API wise outside of the Configuration package. from the current dev to any release.

@BC_Programming

On a random note, has the API for creating a claim settled? I was hoping to implement claim support into PopulationDensity, but at the time I started that, it seems GP was still switching hands and the createClaim() method kept getting changed.