Branch decay [Simple Implementation]

[tillpp]

Introduces a two tiered system of decay.

• Leaves depend on either logs or branches.
• And branches depend on logs.

This means that breaking the logs of a tree is already enough for the whole tree to decay.
This would fix #2331 (comment)

Downsides:
The log search algorithm is more expensive now, since it compares tags instead of the decayProhibitor attribute

Things i also had to introduce:

• Callbacks have a deinit function now.
• the 7th bit of the cubyz:branch data is used for storing the was-this-placed-by-human boolean

[tillpp]

We still got issues for large thin birch trees.
Because the ground is too far away from the branches on top of the tree, any update above 5 blocks above grounds would trigger a branch decay.
Which means, their SBB has to manually be set to undecayable branches. (This can be done in a seperate PR)

[MiniBaker007]

You would have to trace branch directions and consider only blocks branch is connected to.

I don't know if this is what @Argmaster meant here, but this is how I understood it, and what I think would be a nicer approach:

Branches can (or maybe must) depend on a neighbor. So, in the branch rotation data, in addition to the 6 bits required for each possible connection, there would be 3 additional bits* for defining which one of its neighbors a branch depends on, if any. A valid neighbor for a branch to depend on would be either a full block or a branch which connects to it.

With this approach, decaying branches would just require a simple local update rule. You could allow branches to have no dependency and thus never decay, although I think that would just make things unnecessarily complicated, without much benefit.

*3 bits for 2^3 = 8 possibilities; we need 6 or 7.

[tillpp]

I think that would just make things unnecessarily complicated

Yup
and in addition: branches can depend on more then one direction. (for example: the branches that spawn at the ground, without leaves and trees in frosty biomes)

[MiniBaker007]

the branches that spawn at the ground, without leaves and trees in frosty biomes

I'm not sure what exactly you're referring to, and I don't really understand how a branch would need to depend on more than one neighbor, unless you had two branches coming together and merging into one?

Edit: If you mean like the dead branches on the ground, I'm not sure exactly how they are generated, but I suppose it would be a good example of where having no dependencies (i.e. never decay) would be desirable.

[tillpp]

the branches that spawn at the ground, without leaves and trees in frosty biomes

I'm not sure what exactly you're referring to, and I don't really understand how a branch would need to depend on more than one neighbor, unless you had two branches coming together and merging into one?

this: ( in this case i found one that had 2 connection points to the ground, but there are bigger ones)

[MiniBaker007]

Edit: If you mean like the dead branches on the ground, I'm not sure exactly how they are generated, but I suppose it would be a good example of where having no dependencies (i.e. never decay) would be desirable.

Editted my comment just before I saw your response.

[tillpp]

yeah, anyway way to complicated without any benefit,

[tillpp]

Ok, just to clarify:
There are alternative approaches to implementing this.

And to keep this PR clean of any of those alternatives that would require a >>complete rewrite<< of this PR,
i would like you to discuss it here:

#2331

To keep this PR only about this implementation.
And if we find a better idea for implementation, we create a new PR for that and close this one or keep them both alive for comparisons. (I will rename this branch soon, to differentiate them)
That way, it is also less confusing, which comments refer to the old and which one to the new implementation.

[tillpp]

I think the Merge might have broken some stuff,

going to fix that when i have time ,not now

[IntegratedQuantum]

I'm not sure if they should decay. They are really not like normal trees.

[tillpp]

yeah, I only did this, because carrie requested it: #2334 (comment)

[tillpp]

@careeoki what do you think now?

[careeoki]

They don't have to decay if we don't want them to. My main concern was palm branch and cactus arms

[tillpp]

Don't merge this jet, there are two issues:

first: @Argmaster s optimization #2334 (comment) that i implemented in b42d73e is in principle good, but it works under the assumptions, that branches are not faulty. Like for example issue: #2368 . Because of that, branches only decay half way or never.

second: when breaking a thin birch tree, only the middle part decays, not the branches on top, i haven't figured out yet why, investigation on going.. (or when i have time),

[tillpp]

Found the cause of issue 2:
The trunk of the thin birch trees are connected at the top to the leaves. And since leaves are full blocks, the branches don't decay, a side effect of : #2334 (comment)

I think that branches should only decay if they aren't connected to a block, so a little sapling wouldn't wither away if you just placed a block next to it. Plus free realistic expectations!

I see two possible solutions:

1. I remove @ikabod-kee idea and revert back to my original idea. This would also solve the first issue. but we would have to tell small bushes SBBs to use undecayable branches.

or
2.letting this be a problem, that future PRs can solve by editing all SBB and deconnecting all branches from leaves.

what do you guys think? should i use solution 1 or 2

[careeoki]

letting this be a problem, that future PRs can solve by editing all SBB and deconnecting all branches from leaves.

I don't think this is a problem, you can't connect branches to leaves (as they are transparent). The only reason this happens on the thin birch is that the simple_tree structure is using birch_branch:0b11 to "illegally" connect to leaves.

We can fix the trees by changing the top to this state: (I don't know what value this state is)
(line 41 in forest/thin_birch)