Plans for the next OctoberProject release included the need for a block-defined "counter" of sorts. Specifically, this is to implement the new incremental tree growth feature, which have had in mind since the very beginning (only wasn't added in OctoberPlains since it wouldn't look like anything - why trees are 2-blocks tall to this day): A branch would have a growth limit where each growth reduced that counter as the tree grew (adding some randomness to growth direction, this would make trees look more interesting and would grow over time).

That is still the plan, but I realized that I may not need a new block type for this: I could just make leaves naturally work this way. While this would work, I still might create a "branch" type, specifically so that leaves don't get redundant growth events, later on. While I want leaf decay to be implemented, it should be done with an update event (since it is only based on being next to a log block) instead of a periodic polling operation.

In any case, I decided just to use the inflated byte aspect representation for this, since it already exists and is quite compact (especially for sparse data where almost everything is zero - not as versatile as the short octree, but much faster). This is because all the counter cases I am interested in need numbers in the range of 0-5-ish (all decaying to 0).

After thinking about this for the trees, I started to wonder if this could have other uses and I realized that it could be used for liquids to make their flow distance an option, instead of needing special "flow" block types for each liquid. Also, I realized that all plants could use this, so that plants could just have a number of growth phases instead of special block types for each growth stage.

I need to think more about whether these are good ideas but I am so far thinking that they are. Sure, this will require some additional intelligence being added to the renderer, but that is a leaf consumer of these structures so handling miscellaneous things out there is mostly harmless.

Oh, and while looking at some data migration logic, I decided to finally deprecate some old versions, meaning that anyone who has a world they haven't touched in over a year will need to open it once in the current OctoberPeaks 1.13 release before the next (I don't think any such people exist). Not only is this code very difficult to update and test (since it is all about the past trying to live in the codebase of the present), but I found some parts of it which looked like they might have had bugs, but verifying this and fixing it would have been a non-trivial testing effort (making more very old data, making sure that was correct, just to see if the migration was correct).

Anyway, so far, so good,
Jeff.