Tree Decay & Deeper Oceans

[Soupy Delicious]

Just to keep it brief: wood that isn't placed by the player/not connected to leaves or the ground/some other condition, will decay into nothingness (to help address the issues of landscapes rendered ugly and immersion breaking by lightning storms or chopping tall trees down.)

I noticed that you can build pretty high up. No idea how much effort would be required to actuate this, but if everything was either 'moved up several tens of blocks, or if simply the ocean 'ate' into caves real estate for the purpose of deeper, scarier oceans.

Just imagine being able to take wood from a massive jungle tree to know that it'll eventually 'fall down', leaving things looking nice and clean.
Imagine Being in the middle of the ocean and the bottom not being not 15 blocks below your cheeks.

If anyone has any idea of whether this would be practical to impliment, let me know. Who knows, maybe I'll get off my butt and work on it

edit: To clarify, the ocean 'eating' into the earth's 'real estate' beneath it, would only have to be upwards of 20 extra blocks to effectively give the 'deep, dark ocean' effect.

[EpicAaron]

I don't know about deeper oceans, but more radical height variance would be cool for terrain generation in general. I'd like to see sweeping valleys, gorges with rivers running through them, and even flat expanses. The 1.5.2 terrain generator keeps everything at about sea level, and land is never generated below sea level unless it is filled with water. The vanilla biomes are very uniform, which suits BTW's default hunger balance well but is otherwise super repetitive.

Imagine a "wasteland" biome that is just level sand and bare dirt a day's walk in every directions, maybe with some burnt out trees like something out of a Cormac McCarthy novel. Steve would be pleased to not have to jump up rolling hills constantly, but the desolation counters that convenience.

Sheer cliffs of stone could mark the boundary between biomes at different height levels, creating an interesting design challenge for the player to tackle. Do you circumvent the cliff? Do you build a ramp along the side? Do you tunnel through it? Do you anchor a rope and scale the cliff face raw? Gorges create opportunities to build bridges, and the player enters an interesting survival situation when they accidentally fall into the rapids below.

If deeper oceans mean less nether portals generating underground, then I am all for it :)

[Soupy Delicious]

-snip

I'm sure you've tried it, but I found that the Better Terrain addon addresses a lot of that. Seen some amazing landscapes, bringing me back to the Beta days (even as I'm not playing on Beta Terrains). And with the climates, you can have situations where there's snow or desert for long stretches. I think a problem with BTA is that it'll spawn a jungle biome with the same weight as it'll spawn an innocuous meadows biome. It's cool to have a big jungle blocking your progress forward, offering an obstacle in the landscape. I feel like BTA put too much consideration into making cool biomes (of which they all are) and not too much into making challenging biomes. (Not to say that there aren't challenging biomes in BTA, just think some could be a bit more hardcore. I flew around looking for a jungle in creative for 25 minutes just now, couldnt find a single one)

[EpicAaron]

Yeah, BTA completely refreshes the 1.5.2 experience. It used to be very forest heavy, but Dawn added more plains-type biomes so I am placated :>

What I want though is something more extreme, like random mega generation. A meadow plateau touching the clouds followed by a sheer drop (like the farlands from beta) into another biome entirely.



Oceans that generate fathomless depths would be cool aesthetically. The current oceans have a bottom that sort of loads into the render distance in an ugly way. Too visible! Gameplay-wise, though, oceans are sort of a deserted biome regardless of how they look.

[Blacklands]

I absolutely second the wish for "tree decay".
Maybe I'll even try to make an add-on for this myself.

While playing with Better Biomes, I constantly found myself aesthetically enjoying all the huge trees it features, but absolutely hating to actually interact with them. Cutting tall nested trees down in Minecraft is not fun to me, and it's even harder in Better Than Wolves. Tiny trees are kind of boring, but I often wish all trees were tiny just so I can actually cut them down.
I want to have my cake (powered or not!) and eat it too.

If the tree wood blocks would just start respecting gravity after being disconnected from the ground for long enough, so they fall down (removing leaf blocks under them in the process), that would be good enough at least for me. Eventually all wood from the treetop would be lying on the ground, and the leaves would naturally decay. If you want to have the wood, you still need to break it, so it's not like this makes getting wood much easier (unless you're running out of trees in the area in general).
It doesn't need to be super fancy or realistic.
This kind of happens already now when you burn a big tree down, but only if you get lucky enough with the fire spread, and all the logs get properly turned into their charred variant, so they eventually fall down. If you don't get lucky, some logs survive, which also makes the leaves survive, which means you now have a giant treetop floating high up in the sky out of reach.

[dawnraider]

I've had thoughts about adding the ability to chop trees by repeatedly breaking the bottom block with an axe, using something like the current chewed log model to indicate progress, which would help with that.

[Blacklands]

Could the tree cutting stuff be done by an add-on, in theory?

Right now afaik the game doesn't really keep track of what a "tree" is, at least after terrain generation is finished, does it? There's just individual log blocks.
You can look at the neighboring space for (naturally generated) log blocks and find other log blocks and "walk along" like that, and try to find all log blocks belonging to that tree. But creating a heuristic that gets this right at least most of the time, for all kinds of trees, seems pretty hard. Sure, it's probably relatively simple if there's only one tree, but if there's a bunch of trees that are very close, especially trees with wide crowns that extend far outward, sounds a lot harder. The vanilla game already gets this wrong often for leaf decay, where leaves from one tree will stay around because they're too close to another tree next to the one you just destroyed.

I also don't know if regular blocks without extra metadata could even store this information at all, with how the game works right now. Afaik there is metadata that stores whether a block was naturally generated or placed by a player, isn't there? Could another field be added to log blocks that just stores (during terrain generation) a unique identifier for the tree the log block belongs to? Right now, it seems this is not being done, is it? Is it not possible (or at least not without downsides)?

If it's not possible, all we would have would be heuristics to figure this out, I suppose.
I assume we can manage to figure out if a log block is part of the trunk, and whether the trunk has been fully chopped through (a little harder for trees thicker than a single block, but likely doable?). Hopefully in a general enough way that it works for all kinds of what we would consider a "tree". But then finding all the other log blocks that belong to that tree, without also getting log blocks from neighboring trees, seems quite a bit harder. Depending on the tree shape and how close other trees are, we might frequently delete/drop blocks from neighboring trees, too - or miss blocks from "our" tree because we thought they belong to another one. Maybe in practice it wouldn't be much of an issue because most of the time, trees are not that close to each other, or if they are they're probably trees with simpler shape where determining which tree a log block belongs to is fairly easy (as in, our heuristic will get it right in the vast majority of cases).

[dawnraider]

Leaves store if they are natural or player-placed, though logs already use all 16 states. Best way to do it imo would just be to trace the logs like you mentioned, and then only activate tree-chopping behavior when the logs are contacting natural leaves.

[Soupy Delicious]

Leaves store if they are natural or player-placed, though logs already use all 16 states. Best way to do it imo would just be to trace the logs like you mentioned, and then only activate tree-chopping behavior when the logs are contacting natural leaves.

Would it be possible to sacrifice one of these 'states' (what-ever that is - total layman idiot over here) for the purpose of solving this floating tree issue? If it's a small sacrifice, it may be worth it. It'll definitely allow me to turn on the cool tall-ass-trees biomes again ;)

[Blacklands]

Hmm, yeah, that's an even more difficult situation than I thought, then. I somehow thought all blocks know whether they've been naturally generated or placed by a player, but it's actually just leaves. So we would definitely need to look at the leaves too, and be really careful. Imagine you build next to trees, possibly using logs as scaffolding to hold other non-floating blocks, then you break one log and it breaks your whole scaffolding and brings your roof down because it was too close to natural tree leaves and the algorithm assumed you just cut down a tree...

So blocks have 16 "slots" that can be filled with additional state (that's before you add tile entities, which you generally want to avoid for performance reasons, right?)?
Do they share space, or can they all be up to a certain size? (Is this, like, low-level "you get X Bytes and you can put in whatever you can fit"?)
What are the 16 states that logs have right now in BTW? Are they all in active use? I also wonder if one could be sacrificed to make room for at least an "is placed by player" attribute. I was hoping for a UUID (unique per tree, at least "unique" enough that any overlapping trees would have a different one each), but that probably won't help much if we don't even know if the block was naturally generated or not - that would be more important to know in terms of tree chopping code.

One state is orientation, right? Then there's the wood chewing (how many is that, 6?). I assume two more are the smoldering and burnt variants? Then one more for whether it's a stump or not, maybe? What are the rest? It's not the type of wood, that's a separate block ID... or is it?

Now that I remembered about block IDs... could there potentially be a way to just split this up over multiple block IDs (we are not limited on those anymore, right?)? As in, convert some of the states for log blocks into separate block IDs? Stumps could be their own block, maybe? Could charred and burnt logs be their own block ID, in theory, too? (Can a block replace itself with another block of a different ID when something specific happens, like it burning down? For that matter, what happens when stumps are converted to a workbench? Are those all also Log block states, or does it replace the block?)
But then that might have issues for existing worlds, potentially? (Tree chopping might only work in newly generated chunks?)
I faintly remember reading in the patch notes that the stone stratification layers were converted from block states into separate IDs, weren't they? I guess that's the process I'm thinking of here.

(This is all coming from someone who has never seen Minecraft source code before.)
EDIT: I tried to look at the source code, but I couldn't even find all the states there. They're not all in "FCBlockLog" it seems? Is some of this stuff already separate block IDs, actually...?

[EpicAaron]

Rotation eats up metadata (think of all the ways you can place a log), so every unique way a block can look is generally taking up data real estate.

[dawnraider]

Yeah the state value is just a 4 bit value that you can put anything in, but you can't exceed.

All 4 log types are the same block id, and there are 3 rotations, so that already eats up 12 states (independent state properties are multiplied), and then stumps are the other 4. Every type of chewed log is its own block id (3 rotations plus 4 stages means each chewed log takes 12 states). Burned logs are already their own id, and work stumps are all a single id (currently 8 states used there, 4 for type and 2 for stage).

Stone types are complicated. Strata, and the first break stage, are handled through stone metadata (6 states), but stages 2 through 17 are a block id per strata with all states used.

Technically it would totally work the separate out logs into separate block ids, but as you mentioned that would have the downside of only working in newly generated chunks. Block IDs are still limited, but much higher than vanilla 1.5 (4096 instead of 256). It's not really a concern unless you start adding hundreds of blocks (which uhh... is why block id limits are actually a factor for deco :P ) Theoretically old logs in contact with natural leaves could be converted to new natural logs, then old logs in contact with those could be converted as well, so maybe. But that also gets weird because it relies on a process happening over time, and if a player comes along before its done that would lead to really strange behavior when chopping down the tree.

The UUID idea doesn't work at all because Minecraft has no idea what a tree even is. To the game, the tree decorators are just another kind of feature placer, the game has no idea what's being placed there, and stores no information once it's placed its blocks.

All of this is kind of moot anyways though since imo there's nothing wrong with just checking if the logs are in contact with natural leaves. The only real downsides there are that 1) in niche cases a player-placed log could get picked up and 2) it wouldn't count trees with the leaves stripped, but that's super minor. There's already mods for modern MC that work in this exact way and they work great.

[Soupy Delicious]

Consider player-placed logs decaying next to natural leaves as natural rot. Shouldn't have left the wood next to something moist and organic xD

[Blacklands]

Thanks for the elaboration, Dawnraider!

Just 4 bits per state, huh? Yeah okay that's not much. So orientation and the like need multiple states already. And then log types are also state right now. I also didn't know they're multiplied like that.

As for the UUID, I was thinking it could be added to tree log blocks during terrain generation, by the code that generates the trees. (4 bits is woefully little for a UUID. Maybe it could be stretched over two states to get 8 bits. It would only need to be unique for each small cluster of potentially overlapping trees, so that the chance of two trees that are overlapping getting the same UUID assigned to them is very small.) It would just be pseudorandom, no need to know about any other trees apart from the one that is being generated right now. And I know the game doesn't know what a "tree" is, I thought that's why we were talking about adding some metadata to log blocks in the first place? If the game knew what a tree is, this whole thing would be trivial. :D
But maybe it still wouldn't be possible with how the terrain generation code works.

Good to know there's already vanilla MC mods that work with just a heuristics-based solution! Then I guess we know where whoever wants to take a crack at this at some point can get some inspiration from. :P
I'm not fully convinced that it would be good enough especially with more complex overlapping trees, like some from Better Biomes. I guess destroying player-placed blocks would almost never happen, but I wonder about cutting down parts of neighboring trees as well as the one you're actually cutting down. Though honestly I'd rather have janky behavior like this than not be able to cut tall trees down at all...

[dawnraider]

I mean cutting down neighboring trees is definitely a thing that happens, but I'm not particularly concerned.

Just 4 bits per state, huh? Yeah okay that's not much.

It's not 4 bits per state, it's 4 bits total to contain every state for that block, which is why there can only be 16 unique states. It would be interesting to have each tree randomly assign a data value to its logs and prevent chopping down of logs without that data value, although that still doesn't get past 1) the data values being fully used already and 2) would only work in newly generated chunks.

[Blacklands]

Oooooh okay, that's where the 16 states come from, it's just 4 bit in total. :D
Yeah okay nevermind then about UUIDs and the like.
Cutting down parts of neighboring trees sometimes is fine, I guess. And it would only ever potentially happen if the trees are the same wood type, since we can check for that at least.