Bukkit

I'm sorry. The project got stuck again and I don't want to promise anything anymore because I feel I keep disappointing you... :/

One day it might arrive... I wont announce anything until it's almost done.

(However motivation has severely dropped to develop such a complex plugin in the light of bukkit dying... also there is no staff approving plugin files anymore so the only way to distribute new releases is by linking to them directly - which violates the rules - but there is also no staff enforcing those rules atm... it's all a mess!)

So once again I've decided it's going to take too long to get it finished to the state I want - therefor I will try to release S.A. v0.9 in a not too distant future.

It will probably be a slightly upgraded version of the current v1.0 pre-release - with added piston mechanics. Which, as it turns out after I did some thinking, is actually quite significant: combine it with a block crushing mechanic of your choice and it can be used to create fully automatic tree farms!
(It will ofc. be possible to disable piston-push-replanting if this isn't desirable.)

Also want to give an early heads up that soon after v1.0 I will change the config system.
I'm not going to do it in v1.0 because I promised the old beta configs would load up in v1.0...

Basically I intend to add the ability to create groups, which will be configured the same way as players in the current config, and then individual players can be added to these groups. (Exactly how players gets added to group(s) isn't decided yet... maybe with permissions?)

~ ~ ~

Edit1: Adding piston mechanics presented some new challenges related to when to actually perform the replant. Therefor I've come up with a new idea:
Seed-mechanic - basically this means that if a replant fails to happen after the desired delay, an invisible "seed" will be "planted" at that location instead and it will lay dormant there until the world conditions allows it to grow. (To maintain good performance this will have several limitations and the seed will not remain forever - I have several ideas but have yet to decide which approach is the best.)

~ ~ ~

Edit2: Well again things get more complicated... this time I've encountered a very old unresolved bukkit bug (1.4.7 - 1.7.9): BUKKIT-3523 ... I already have a good guess as to the cause of the bug (see the comment by Edhill Ost) but expect more delays while I experiment on how to best work around it... :/

~ ~ ~

Edit3: So I started writing some code to deal with the bug (by filtering out "extra" piston events) however this isn't a very cheap thing to do. I mean it's not that expensive, but imagine a few pistons firing of and a few plugins all running some form of similar filtering and... well it's still not that expensive to be honest... more like it has moved from the realm of non-detectable to probably-measurable... but... it displeases me... :/
So I intend to make an open-source solution for it (in my AZTB collection) that will allow many plugins to share a single filter to improve performance (*cough* assuming anyone actually end up using AZTB for another plugin *cough*).

However (<-- notice how the project starts to derail / grow into something completely different) this "solution" tool-class needs to register some things with the bukkit server, like events for instance, which require a plugin as the subscriber, and... it wouldn't make any sense to attribute these registrations to any single plugin using the tool-class! Optimally they should be attributed to all the plugins using the tool-class. Picking one at random is just asking for trouble! (What happens if that plugin decides to unregisters its events or gets disabled: everything breaks for all the other plugins <-- not acceptable!)

Essentially I need a separate plugin just for the tool-class. However this is something I've always been trying to avoid. That means everyone using my "solution" would need this plugin as a dependency + needing to interface with it safely + more trouble for the end user: needs to keep track of / install more plugins = bottom line is this is too inconvenient. So how to solve that problem in a simple way? :D

Well I've written (wip) a new little set of tools I call RuntimePlugins which enables you to create plugin classes that can be loaded onto the bukkit server directly from code without the need of a separate plugin file! (I don't know why bukkit made the design limitation that every plugin needs to be loaded from a file on disk, maybe there is some reason..? Well whatever... worked around it!)

If this works it opens up a range of interesting possibilities like...
Multiple related plugins in a single jar, that loads or unloads themselves from the "main" plugin based on configs / conditions / whatever.
Copy-paste tool-classes that can self-load self-contained plugins.
Probably other things I haven't thought of.

...the second one is what I need for the piston fix, which I need for S.A.
Now I just hope loading plugins inside of other plugins isn't somehow violating any bukkit rules about plugins...

tl;dr: Need plugins loaded directly from classes to make piston fix, need* piston fix for S.A. piston mechanics - have almost finished first part, have made some progress on the second part, have made small progress on third part.

...also need a basic seed-mechanic implemented before I finish piston mechanic.

Enjoy wall of text. :)

@d3voo

Sorry, have been devoting my free time towards AnimalsDropMeat lately.

I will probably get back to SA after this ADM work (no promises)...
I do have a lot of plans for SA beyond v1.0 but...
it will take a lot of time before I get there.

Due to work I currently have a limited number of hours I can devote to coding each week.

Regarding the 1.0 release, it is basically be the big refresher of SA code - a robust quality foundation, but the feature set won't be overly exciting. Beyond v1.0 is where I will start to add actual cool stuff, but almost all the features I want to add are pretty advanced and thus each of them will require plenty of time!

To conclude, SA is a big and slow project. As long as I only have a few coding hours per week it is going to take months or even years to grow into the awesome plugin I want it to be. The word 'cultivation' feels very fitting... a sort of patient loving care with big dreams and hopes :)

My other plugins being smaller means they can be upgraded faster. Pausing SA development to put in a few hours of work to upgrade a smaller plugin allows me to retain that happy feeling of productivity. That's very important too - this is a hobby after all :)

@d3voo

Hah, someone actually read a bit of that wall of text? :P

Progress on SA has almost halted as you can probably tell from the stop in weekly news updates, however it's not dead, I intend to finish it. However there is a pre-release ready, if you want it you can pm me. (It lacks the show and override commands because I started making a framework for smoother handling of "flags" / command arguments - where I sort of got stuck on a tricky piece of code. So I lay it aside for some time, been doing some other stuff (and busy with private things) to clear my head a bit. Still have a half-finished code-flow diagram laying on my desk for it...)

tl;dr
It's on a short pause, pm me for pre-release version, will get back on it some time soon.

Thanks for the cheering!
Makes coding more fun! :)

Edit1
Just wanted to point out: The pre-release is stable, it's not some buggy test code or anything, we are running it on fudzer.se in 1.7.2, it just has unfinished features and that's why I'm holding off the release (1.0 is a big number - needs to be complete!)

Edit2
I have yet to make an official statement or reveal, but the SubCommand-framework is now actually available for download from github as part of my AZTB-collection "AnorZakens-ToolBox" of small frameworks, tools and other useful classes (mostly aimed at bukkit developers). It's LGPLv3 licensed so if anyone feels like having a look or use any of it they can find it here: https://github.com/AnorZaken/aztb
It's working nicely, only lacks custom formatting of description-texts, but that's a somewhat superfluous feature so I'm actually considering removing it instead of completing it.

Edit3
I haven't uploaded SA to github yet, but if anyone is curious about the "tiny" changelog I've keept mentioning for SA v1.0 here is a paste http://pastebin.com/gGZugPud :P
The top part is future plans (>1.0) followed by the todo-list (unfinished stuff for v1.0 release) followed by a massive section of already implemented changes! (>150lines!) For comparison the changelog for the previous release is included at the bottom (<10 lines... xD). If anyone is curious about the current state of SA development they can check it out.

Got some good and some bad news, lets start with the bad...
Basically I'm a "little" annoyed at myself because just yesterday I finished a new part of the code and... well once it was finished I sat back and gave it proper scrutiny, only to realize it was feature-creep. (Yes, I should have realized this sooner - that's why I'm very annoyed at myself!) Sure it was nicely optimized and cleaver, but the usefulness of it was... lacking. Bah... I made a mistake... I got carried away by cool ideas and creativity! >:(

So after having spent a lot of hours on this feature, I'm now going to spend, well hopefully not more than two hours, removing every trace of it. (Three whole classes going down the drain! - Really not looking forward to the the huge amount of documentation changes this will require!) ;(
The gods of Quality and Performance can be harsh and unforgiving... But there is this saying when it comes to design that to get the best possible result you sometimes have to kill your darlings. And no extra code at all will always be faster than extra fancy and clever code, no mater how optimized or clever it is!

Now on to the good news!
The SubCommand-framework is ~95% finished. The last 5% is a bit of extra stuff for command full-description text formatting and the cleanup after the bad news above. So basically the new features in the SubCommand-framework (the not-going-down-the-drain ones) are automatic and customizable formatting of all text, like usage, description (in progress) and alias - for performance reasons these formatted strings are cached. And some general improvements here and there... many smaller improvements that would be too boring for non-programmers to list here.
(The design and default formatting style is inspired by WorldBorder - only it's in an easy to use framework so as soon as I release it you can make your own nicely formatted commands with very little code effort!) :)
(Also the HelpTopic (now an abstract class) is finished.)

. That's that...
Getting glimpses of light now, starting to see the end of the tunnel. I don't foresee any more changes to the SubCommand-framework so I think it's pretty safe to promise the completion of the show-commands to next week, hopefully more. Until next time! ;)

(Next progress-update will be released tomorrow, need sleep first, sorry for the delay)

The past week has been mostly (important but) tedious work.
Improvements have been made to many of the reusable components I've created with S.A. Since they are open-source and intended to be usable by others they need to be as easy to use as possible - preferably detecting breach of contract / incorrect usage.
So aside from writing tons of javadoc I have also spent time improving their robustness.

Aside from writing the javadoc for these components themselves I have been improving the multilingual support on them. Mostly a lot of work making it well documented, consistent across components, and optional!

Making language support optional was important because even though I will probably always make multilingual plugins from now on - given all the reusable code I've already written for it - I don't want to discourage others from using these components by forcing them to provide such content.

Regarding SaplingAssist itself I have finally added support for '*' on the gamemode-level in sapling.yml! This means that more compact configs are possible.
Why this wasn't supported before was a combination of design choices and technical factors... (All arguments against supporting it disappeared together with the old code.)

So how did it go with the commands I was working on last week?
I put that on hold since documentation work had been piling up for a while and I wanted to get all that stuff out of my head and out of the way before continuing to write new code. I'm nearing 5000 lines of code (&javadoc) so more documentation makes a lot of sense.

. That's all for this week!
(Sorry, no new performance improvements this time - it has mostly been a week of improving reusability and documentation!)

So progress has been a little slower the past week, but I'm back to assure everyone that things are still rolling! Some of this may be a bit technical / in-depth but in the least you can rest assured that progress is happening and the release is slowly and steadily drawing nearer.

So among the things I've been doing recently is, aside from a general bit of polish here and there, finished the reload, check and download commands, as promised. Currently I'm putting the show/showextended commands in place.

Since these commands use my (FILTER*) syntax for specifying the target (as will the override command) - and I didn't want to repeat the description for the FILTER syntax in all of these command descriptions - or make the descriptions for these commands overly long for that matter - I realized the usefulness of supporting non-command help topics in my SubCommand-framework. So right now as I'm typing this I'm putting the final touches on IHelpTopic for the built-in help command for SubCommandGroup.

Earlier in the week I made some changes to the code that gives support for other languages / translations. Since this is my first plugin, and version of that plugin, with this feature the code has undergone a few improving changes over its development time. The last such change was that this week I broke out a bit of the language code from S.A. into its own standalone component, i.e. I made the basic part of the translation code reusable for other / future plugin projects. Doing non-critical changes like this will of course delay the release of S.A. v1.0 a bit. But in this regard I believe quality trumps a speedy release!

Oh, and of course performance is always a main focus. Most recently I further optimized re-registration of event-listening when reloading the plugin config so instead of deregistering all events and then re-registering the events that are needed based on the newly loaded config settings, I now deregister only the events that are no longer needed, and likewise, register only the (needed) events that where not already registered from the previous config load. Quite a small optimization I know! ...I just want to keep you convinced of my never ending dedication to performance!

. That's about it for this week!
It takes it share of time, but just sit tight - my long-term goal for SaplingAssist is to transform it into the #1 must-have plugin for foresting and sapling management! ;)

Replanting and protection code is 99% complete. (The rewritten plugin has been in a runnable state and I have been testing it on my test server since a couple of days back).

Also did some minor updating of my plugin-updater code that I have been using for all my other plugins, and that will go into the next release of S.A.

Currently almost finished writing a small framework for easy managing of "sub-commands"**. Supports easy adding/removing of commands at runtime, automatic help-command, automatic permission checking and tab-completion, as well as changing command-names and aliases at runtime AND promotes good code structure!

**By sub-command I mean when one command "splits" into several options; e.g. if we have "/saas reload" and "/saas check" then "reload" and "check" would be two sub-commands of "saas".

The latter is relevant (changing command-names) because next release of S.A. will be my first plugin upgraded to become truly multilingual! ^__^
Everything from command-names and command descriptions, to ingame messages and console error-messages can be changed with a translation file! ^__^

As far as I'm aware this might actually become the first bukkit plugin ever that allows you to change command-names?

(Might be slightly overkill, but it's purely optional, you can even translate only the parts you want. After a user requested the ability to have non-English names for a thing in one of my other plugins I figured I might as well start thinking about good ways to accommodate translation into all my plugins. Because why not take it to the next level!)

Read this far and worried about performance? Don't be!
All code I've rewritten for S.A. is super optimized, I don't even register events normally because standard EventExecutors use reflection to call event methods - and by registering on all events manually I can even optimize so I only register on the events that are actually needed based on your current config. Shave away that 1ms of extra processing!
(Seriously, I don't even use String.split to split strings. I use Pattern and Matchers directly (what gets used anyway under the hood) to optimize away any extra processing or source of gc load.)

Much of this is of course slightly overkill, and you would normally never spend time optimizing that hard, but I love doing it - to me it's not about whether or not it's worth the time spent, for me it is intellectual entertainment! :)

Anyway, currently finishing up the work on that sub-command stuff, and adding a few easy-to-add commands like reload, check and download.

Next step will be to re-implementing the show-command. Then I will start working on the one major part that is remaining: The new override-command!

What is that? Well I figured that in-game support for modifying the config is not only a feature that is seldom used, it is also a feature that can never become perfect when time comes to merge new settings to disk etc... so that feature will kick the bucket. The override-command is it's much more logical and more powerful replacement!

The only real useful reason to edit config ingame anyway is to temporarily change settings when yourself (or some other user) needs to perform some special task. For instance: maybe you want to clear a forest away from some region. This is what the override command will be for! It will allow you to temporarily override any setting on any level (server/world/player/mode) to accommodate for those times when you need to bend the rules a little.

"But wait... you didn't mention new saplings / trees?!"
But that's such a chore >__> ...do I really need to?
...That was obviously the first thing I fixed, duh! :P

*This might seem like a wall of text, but then again you have yet to see the change-log! :P

@Baffu

If I'm lucky I will get around to it very soon. Basically I've had a lot of personal issues and haven't been feeling too well for a long time or I've been busy or both. Anyway...

I do believe this plugin has suffered from feature-creep*, and basically I intend to rewrite it from scratch to slim it down (and remove seldom used over-the-top features from it - only keeping the basic replanting functionality and the features that really makes sense). Basically I'm not pleased: I want higher quality - less (feature) quantity. (This plugin was originally only for my own private server and so I added lots of extra features just because it was fun and I felt like it.)

No promises, because I hate letting people down, but I will take some time off to look at it this weekend.
Edit: It is now being worked on.
A bit unsure about the ETA. (Please consider donating if you can afford it)

\* Feature-creep is when you add to much "fluff" into the product - it is good practice to stay true to the core purpose of your product and add only the stuff you really want / need.

@live4redline

99.9% sure I will do it at some point, but 95% sure it wont be soon unfortunately.
I have lots of real life things in the way...

(I initially hoped I would do it this quarter, but probably not :/ )
(I still check the site frequently, in case support/maintenance is needed)

@Baffu

I am aware, but last time I checked the 1.7.2 dev-builds (early December?) the Tree and Sapling-classes of the Bukkit-API hadn't been updated yet, and I didn't feel like writing workarounds for things that would be fixed soon anyway.
They are probably updated by now, but I don't have enough time to update SaplingAssist at the moment. (I intend to rewrite large portions of the code before I release v0.8.0, so I need more spare time before I can make it happen...)