Use leaf distance property to calculate which tree they belong to.

[MobButcher]

Describe the feature

Sometimes trees have connected leaves that stay floating, fully or partially, after breaking one tree but not another. This is because they are close enough to still have distance small enough to be considered a part of another tree.

Modifying the algorithm that analyses leaf blocks would be a good solution:

• If breaking this tree log would cause the leaves to disconnect from the trunk that is being broken, then:
• If a leaf block would have its distance property increased, conclude that it was a part of a broken tree and break it; otherwise conclude that it's a part of another tree and leave it intact.

First condition is phrased in a way to maintain compatibility with all current methods of breaking a tree, full chop and shift down.

[Rakambda]

I don't really know if it's easily doable. The idea is quite nice though. Will see what can be done.

Things to consider:

• The checks are done "lazily" in separate ticks, so need to find a way to have the distance "before" and "after
• Some leaves may not behave the same. Some may simply not decay or not based on a distance (not vanilla ones).

[MobButcher]

• The checks are done "lazily" in separate ticks, so need to find a way to have the distance "before" and "after"

Worst-case scenario, you can re-implement vanilla-style distance checking and compare against that. AFAIK, it's a simple Manhattan distance. That, or you can cache data about leaves and their distance values after breaking a block for later comparison. Though now we run into problem of when to cache: before first block break or before each block break. I'd say before first block break, because if you wait until the trunk is disconnected from the whole array of leaves, some of them will be stuck to another tree with distance:5 and above values, which is unreasonable. And then comes a problem of clearing the cache. Timeout?

You know what? Reimplementing Manhattan distance calculation seems like a good idea, especially if you're using breadth-first graph search, since it ties up perfectly into it with minimal modifications.

• Some leaves may not behave the same. Some may simply not decay or not based on a distance (not vanilla ones).

You already implement a white/blacklist for leaves. You can either implement a second blacklist for this particular solution, make a toggle for leaf types available, or just go lazy: do everything this way and declare other mods that don't fit nicely into this an incompatibility.

[Rakambda]

I'm not sure if this is still relevant. As it is now the leaf ticking feature is totally disconnected from the breaking of the tree.

Air blocks that are updated next to a leaf block is what will trigger the decay speedup.
This was changed because scanning very large trees for leaves caused issues (especially in dense forests where lots of trees are close to each other).

[MobButcher]

It is still somewhat relevant. Leaves don't decay if there is a tree log block at most 7 blocks away in Manhattan distance. If you have two oak trees four blocks away from each other, their leaves will connect into one mesh and most of the leaves will stay in the air, supported by one of the trees.

This is an issue in dense forests, where you might find it troublesome to navigate through the leaves, and in cases when the user wants to keep some of the trees but cut others.

Theoretically you could put the scanning on a separate thread and keep it off of the main one, since starting the leaf decay is not time critical. But I know I really make it sound simple, while in reality it's a huge chunk of work for something that could be thought of as eye candy. Still, that would be awesome and I bet people will love that feature, even if they won't notice it.