Rakambda
commented
3 years ago For now there is some kind of check possible, being the number of leaves around the top most (with highest y value) log.
What are leaves is defined by everything tagged as leaves + whitelist + steams (if turned on in the config).
The idea is quite interesting though.
Just so it's clear, that'd be something that happens on the detection of the tree and not the breaking part. That means that being in instantaneous mode or shift down doesn't change anything to this.
A few points that maybe need some thinking.
Whitelist/blacklist
Honestly I think this part isn't that trivial. Each have its advantages/disadvantages. Plus I think it's not that easy to explain them x)
- Whitelist is cool in a way that only the cases defined in config are allowed. This can reduce the burden for new users (or not really experienced with the config) and have an out of the box config that behaves somewhat correctly by default. But that also mean that every case should be thought in advance and have to evolve with Minecraft (and that's kind of an issue as if the default value should change, once the default conf file has been created, then it won't be modified). Plus I'd say it's kinda impossible to think of everything in advance as if someone plays with other mods we can't be sure how a tree is generated.
- Blacklist would mean that the user have to define every case that he doesn't want. Though I do agree with you that having a blacklist can be quite long.
In my opinion a blacklist would fit this a bit better. The "default" config would be to cut down all trees, whatever is around them (can be restricted with the number of leaves) and the user that wants to override that can provide the blocks/tags that forbids the cutting. Now not sure if anything about the "it'd do a long list" can be done. Honestly i think that this list will be populated as the user see cases where it shouldn't be cut and that the list won't be that that long. As everyone builds with different styles and such probably not all blocks would be in the list. But same point as below, if the player uses other mods then this can make this list even longer.
Having the whitelist would rule out trees way too easily. If someone uses another mod and isn't really into configs then if the trees generates with something attached to them (like a beehive is) then it'll be ruled out by default. Also imagine a tree growing next to a jungle temple. Cobblestone and such should then be added to the list of whitelisted blocks even if it's quite "rare" and instinctively shouldn't be whitelisted.
What happens on a match
Let's suppose this is a blacklist that is used. If a log matches one of the blocks, what should happen?
- The "branch" is stopped but the rest of the tree is still cut
- The whole tree abandonned
Where to match
- Should it be the top most log (like for the leaves)
- Should it be the furthest log (doesn't really make sense in instantaneous mode)
- Should it be for every log
ghost
Just something for you to put into your ”idea box” to consider in the future if you want. :) Maybe you’ve already thought of it, if not:
I was thinking of ways to identify/separate trees from other log/wood structures. Not leaves necessarily, but the logs themselves. What I came up with: (A use case for a "connected block" whitelist)
Test for blocks connected to the log that is to be removed (blocks connected to the furthest log from the cutting point). So for example, if the log is connected to wooden planks or glass it won’t be considered part of a tree and won’t be removed. However if for example it’s instead connected to any of the following: (All possible natural blocks connected to a generated tree[log] I could think of)
In the case of nether ”trees:”
Only under these conditions would it be considered part of a tree and be removed like normal. If anything else is in contact, it’s not part of a tree but some other wooden structure and won’t be removed.
So a config whitelist for blocks that are allowed to be in contact with a log for it to be considered part of a tree and be removed. A whitelist would be better than a blacklist as there are far more blocks that aren’t connected to generated trees than there are ones that are connected (naturally that is).
Visualization of blocks connected to log (barriers being connected blocks):
Senario image below: (cutting point being the lowest log in the image) In a case like this where the tree scan finds a "non-tree log"(log in contact with a non-whitelisted block). I'm not sure if the scan should stop when finding this log and ignore any blocks above/after it and only remove the 3 blocks below it (considering it a dead end). Or if the scan should remove the 1 block above skip the non-tree log and then the three logs below it. So if a "non-tree log" should be a dead end for the scan or not. I'm guessing that a dead end would be more useful in most cases.