I'm using the fabric version for 1.16.4: FallingTree-Fabric-1.16.4-2.8.1

(When using SHIFT_DOWN mode)
When using "above_cut" the discription for it says: "will break only blocks that are connected from above the cut point."
However when you put logs in a row horizontally you can still use shift down to clear that row from one end by simply breaking the other end repeatedly. So the feature works horizontally the same way as it does vertically.
How I expected/wish it would work is for "above_cut" to only break blocks that are connected to the cut point but are also ABOVE IT. A good idea as well would be to have a limit to horizontal breaking when they are above the cutting point. So that one cant clear a 100 block long horizontal row of logs. This wouldn't break the intentional use of the feature, would just leave a stem that one would have to manually clear in 2x2 trees.
All of this could be solved of course if trees could be somehow identified, sadly that doesn't seem to be possible :/

I originally noticed this when accidentally trying this feature on a village farm, I just felt that it was in a way "game breaking" to have this work so well horizontally as well. (might be just me). I feel like this applies more for shift_down mode. As it's more "vanilla-like."

Farm thing:

So in short

1. Have "above_cut" only break blocks above the cut point. (atleast with "shift_down" enabled).
2. Have a limit set to horizontal breaking (when it's above the cut point). Have a configurable number of logs. And maybe have "shift_down" only work if there are no parts on the tree horizontally that are above the limit. Kinda like pistons cant push above 12 blocks.
3. Thanks for your efforts and time :)

If you have any questions I can try to clearify any part of my bad explanation :p

I did the 2 modifications (above is strictly above & added config for a search radius Trees > Search area radius).

Before I port it to forge too and release it you can test it from the jar attached. I guess it'll be simpler than words to know if it actually fits your needs 😉

FallingTree-Fabric-1.16.4-2.9.0.jar.zip

This is exactly what I meant! Works perfect!
Your response time is out of this world :D Thanks you!

Shift down or instantaneous works the same on the tree detection. Just that instantaneous breaks everything at once while shift down picks the furthest block.

Just to have the ideas clear on what each breaking mode does:

• Normal will basically follow a "log path" in every direction.
• Above cut will follow the "log path" in every direction BUT it will be forbidden to go down on the FIRST log (the one you're breaking). It is then allowed to go down if there's a path that doesn't go through that first block.
• Above Y will follow the "log path" but won't be able to go down at any time.

Now on the main topic.
Maybe the way I've done the descriptions are not that accurate.
I should have written that it is above or same height. Maybe that could be change in the behavior though, from what you said it seems to make more sense for it to be strictly above.

=> Would that solve that first part if I change the way the detection is done and make it so that above is y > cut_y instead of y >= cut_y ?

For the config part I don't really get the "only work if there are no parts on the tree horizontally that are above the limit".
Though I guess there could be some sort of config option to define the max radius in which the tree is scanned. Like let's say that this value is set to 2, then the tree will be searched in an area of 3x3 centered on the breaking position. Every path that gets out of this area is stopped.

=> Does that seem something interesting to you or I totally didn't get that part ?

Yeah, my english is a bit wonky, sorry for any confusion on my part.
y > cut_y would be exactly what I meant. Just so that it can't be used on horizontal rows too "easily."
This would solve this senario entirely:

Visualization (axe=cutting point; x=disappearing log):

The 2nd part was an attemp to solve the senario in the image below:
Not completety disable this from working as that would break the intended function. But yeah, what you proposed would work, however only if the search area was unlimited in the y value as trees are always taller than they are wide.

Hope this clears things up!

When I saw the changelog, I thought you had made so that above y is strict, and would prevent horizontal logging, which I thought was a great idea. That is, in the yellow diagram, the bottom branch wouldn't be logged at all (except the targeted block, obviously).

The rationale is that horizontal logging is almost always a player mistake, destroying unintentionally some wood built structure.

Ah yeah I didn't think enough when I did the changelog 😅 These diagrams are actually from before the update.

With the update both the yellow and blue bottom left branches won't be cut.

I wanted to put these kind of infos in the wiki section so people can get a bit more infos on how settings change things, and hopefully an easier way for me to keep it updated.
My bad for the diagrams that aren't updated anymore.