Better log search/traversal.

[Heimdell]

I read on forum, that cutting trees is a bit laggy, and took a look onto the code, which maybe does the thing: https://github.com/Deadrik/TFCraft/blob/master/src/Common/com/bioxx/tfc/Blocks/Flora/BlockLogNatural.java#L245

I'll try to reimplement this traversal using for-loops and queues, instead of recursion.

If I made mistake and this is not the log-enumeration mechanism, please tell.

Also, the ProjectE mod, which has mass-destruction items too, uses so called "loot balls", which are object to pack all the loot in, to reduce lag. Maybe, this is the way to solve the OOM-failure problem.

[Heimdell]

I have a traversal template at https://github.com/Heimdell/TFCraft/blob/master/src/Common/com/heimdell/utils/traversal/Traversal.java .

I want to ask: should the tree fall completely, be cut from the application point or be cut from farthest point?

The problem is: if we cut from farthest point, and the axe wears off before the tree is cut down, almost all wood is stuck on top of the tree thunk of some unreachable height.

My proposal is the next: cut the tree completely, apply some heavy damage to the axe (like, 1/10 * wood_density). If axe has insifficient "health" - break it without touching the tree at all.

However, If you find a better method, i'll convince myself to implement it as you say.

[SamJBarney]

As a TFCraft enthusiast, I personally think that the suggestion @Heimdell put forward for tree cutting is a good idea, though it should only calculate it from the point where you are chopping.

[Heimdell]

@SamJBarney, it could lead to the "floating hat"-style forests.

[Kittychanley]

The way the system is currently set up is that the tree is cut from the farthest point. So if your axe doesn't have enough durability, the top of the tree is removed and the trunk remains. If you want the items that are now sitting up on top of the trunk, you'll either need to pillar up and get them, or make another axe and finish chopping.

[Heimdell]

I could change my implementation to work exactly like that. That behaviour was chosen because it is right or just convenient?

[Kittychanley]

That behavior was chosen because that's how we decided to implement it.. there really isn't a "right" way to do it.

[SamJBarney]

@Heimdell it wouldn't lead to "floating hat"-style forests because it would only chop from that point if it had enough durability, as you specified.

[Kittychanley]

@SamJBarney That really wouldn't be intuitive at all though, because you would just keep chopping the bottom block but nothing would be happening if your axe doesn't have enough durability. And if your axe completely broke and nothing happened that would just make players angry.

[SamJBarney]

That's fine. :)

[Kittychanley]

Each option has it's downsides.

1. Do nothing - Very bad game design considering it will confuse players and is not intuitive. We're here to make a fun game, not piss off players because a mechanic isn't obvious.
2. Break from the bottom up - Results in floating trees that are hideous, and actually will also induce more block updates as TFC already has a system in place that slowly removes any floating trees.
3. Break from the top down - Results in items that may be out of reach for the player, but can be quickly remedied by climbing to get them, or just using another axe.

We decided that the 3rd option was the best of the three considering it's downside isn't nearly as bad as the others. The lesser of multiple evils if you will.

[Kittychanley]

The other important thing to keep in mind is that even with the top-down method, the entire tree is only broken if the player broke the very bottom block. This allows for players to target a block at a different height and leave residual stumps if they so desire.

[kurzninja]

As a TFC player, I agree with Kitty in that the third option is best. Where
I've found it to be a problem is when you have multiple trees that are
connected such that chopping one tree down brings all the connected ones
with it. IMHO, this wouldn't be desired. Is there a way to solve that or
just leave it as is?

On Monday, June 8, 2015, Kittychanley [email protected] wrote:

The other important thing to keep in mind is that even with the top-down
method, the entire tree is only broken if the player broke the very bottom
block. This allows for players to target a block at a different height and
leave residual stumps if they so desire.

—
Reply to this email directly or view it on GitHub
#773 (comment).

Brett G.
5th Kyu LAGWNF student
AIM: togakure99
Yahoo: kurzweil_freak
"I'm actually not petting my keyboard..." - J. Rudess

[Kittychanley]

With the current system there really isn't an easy way to solve it, as there isn't any sort of schematic to let the game know where one tree ends and another one starts after they have already grown.

[Bletch1971]

Just another persons point of view on the tree chopping. I have been playing TFC for quite a while now and I have not really experienced a lag when chopping down trees. I understand how it might happen, in that connected trees are also considered when the tree is felled.

I like the way the tree chopping is done. I think the decision the TFC devs made with this is the right one. Floating trees look terrible and I am also glad that they implemented a system of floating tree removal.

As for the connected tree felling, again I like it. At first I was unsure what was happening, but it did not take long before I used it to my advantage. Chopping down 2 or more trees by only breaking 1 tree log meant less time me actually standing there hit tree logs.

I do not see this as the lesser of the three evils, this solution is the only good one. MC tree felling is long and laborious and creates floating trees that you need ladders etc to get to.

[Heimdell]

How about:

1. limit volume per-cut to some value (1000 blocks?);
2. cut whole tree each time.

(2) will not give any advantages to the player, but will greatly reduce the inconvenience and remove need of search for the farthest point.

I'll try to implement this and test how it works.

[Kittychanley]

@Heimdell That completely defeats the point of the tools having durability though. As the system currently stands, each durability point will break 1 block, just like how durability works for every single other tool in both modded and vanilla Minecraft.

Also please realise that we are not planning on any more major updates for TFC, only minor hotfixes. So if you wish to submit a PR for this, from a player's point of view it should behave essentially the exact same way as it currently does, just with performance increases behind the scenes.

[Kittychanley]

One thing I noticed while looking over the code you started, Leaf -> Wood is actually necessary, because otherwise players won't be able to chop down willow trees, which have branches that can sometimes be completely surrounded in leaves.

[Heimdell]

I plan to rewrite wrote the "vicinity" method to implement the 26-neighboarhood (3x3 cube). The willow tree blocks remain (at least) diagonally connected to each other, so It should work. It works in mocked envionment (2D int array).

[Heimdell]

I added test run (https://github.com/Heimdell/TFCraft/blob/master/src/Common/com/heimdell/utils/traversal/Test.java) to demonstrate that diagonal connection actually works.

[Heimdell]

By "cutting whole tree each time" I actially mean "... and apply the damage to the tool". So the tool will still be able to cut, say, 5 Douglas Firs instead of 4.5 & 1 Sequola instead of 2/3.

[Kittychanley]

That feels a bit exploit-y for when a player has an axe that only has 1 durability point left on it and they can go chop down an entire huge sequioa.

[Heimdell]

It is, but how frequently does the player end with 1-hp axe? It isn't used as vanilla one - to chop tree one block after another - it is used on whole tree.

The other way is to add some "loot ball" entity, which will consume all cut products and give them to player on contact, if he has free place. It should remove lag from having too much items laying on the ground.

Theoretically, the only part of the tree that should be cut for tree to fall is 1 meter high cylinder, but, as I understand, you've tried to model converting one big thrunk to logs.

[Heimdell]

We can also add logs directly to the inventory (by removing the farthest blocks). Lumberjacks rarely "explode" the tree with their axes so the logs fall all around (only on the critical hits, I presume ;)

[Kittychanley]

As stated before, any changes made must be behind the scenes as possible. From a player's point of view, other than the items dropping (which I've already figured out an easier solution which can already be implemented instead of "loot balls" which would look odd and out of place) the tree felling mechanic should behave exactly the same. The tree is chopped from the top down, and each log block that is broken costs 1 durability point. If the axe runs out of durability, then it just chops from the top down as much as it can. If the axe has enough durability, the chopping should stop at the height at which the player broke the log block, and not continue any lower.

The burden of "proof" that our system is better is not on us. It is on you to prove that any different system implemented would be better, because otherwise we're just not going to merge the PR.

A single sedimentary stone axe has 50 durability. A single large sequoia tree has about 100 log blocks, so not even 1 full durability stone axe is enough to chop the entire thing down. And if you used a two metamorphic stone axes at 55 durability each to chop the tree down, you'd be left with a single axe with only 10 durability points on it. That axe should NOT be able to chop down another 100-log sequoia.

[Heimdell]

... at least you can use that traversal somewhere. There is Test.java as usage instance.