It seems like large oak trees haven't been generating naturally in the past few snapshots. I mean the ones that are about twice as tall as normal oaks, have horizontal branches extending from the trunk, and have about 10 times as many leaves. About 1 in 20 saplings will still grow into large oaks, as normal, but they don't seem to be generated in the wild during the initial world creation at all, even in large forests where they can normally be found more commonly. Can anybody confirm this for me? Were they removed for some reason? Or are the requirements for their natural generation impossible now, due to changes in the world generation process?
Yeah, I have noticed that too... Sapplings will grow normally into big oaks sometimes as normal, but I can't find them in forests anymore.
If it's a bug, they should fix it. Big oaks are great part of the forest
Yeah, I have noticed that too... Sapplings will grow normally into big oaks sometimes as normal, but I can't find them in forests anymore.
If it's a bug, they should fix it. Big oaks are great part of the forest
I see them still in rain forests. I don't know about regular forests though.
Yeah, I have noticed that too... Sapplings will grow normally into big oaks sometimes as normal, but I can't find them in forests anymore.
If it's a bug, they should fix it. Big oaks are great part of the forest
Absolutely. They give forest biomes a sense of age, and they improve the landscape by breaking the monotony of all the other little 'lollipop' trees.
I know for a fact that large oaks were removed from forests in 1.7, but they should still be spawning in extreme hills and ice plains. They should be found in jungles too.
They do grow on the sides of mountains in the extreme hills and I've seen them in ice plains too. I remember some changelog where they were removed too.
I'd really like to know if it was an intentional change, or if it is a bug that needs to be reported. I really liked the big oaks.
They were removed because of "lag", although instead of blaming the trees I'd blame other code in 1.7 for that (in 1.6 jungles are no problem for me; in 1.7 the game goes into fits as if it is going to crash any second when I enter one, taking a few minutes to stop lagging - no wonder they made them much rarer; at least the 1.8 snapshots seem better).
Not to mention, considering that they aren't that common, how would they have such a huge performance impact anyway (in the BiomeGenForest class in 1.6.4 there is a 20% chance of birch trees, then the other 80% are oaks, with 10% of those, or 8% overall, being large oaks)?
I know for a fact that large oaks were removed from forests in 1.7, but they should still be spawning in extreme hills and ice plains. They should be found in jungles too.
Damn, if there was some sort of lag problem that came in around 1.7, maybe there may be a fix and they could reappear in 1.8?
There is a bug report, but as I mentioned they were intentionally removed, so not really a bug (the real bug is whatever causes a huge performance drop in 1.7 when there are lots of decaying leaves, as I'm pretty sure they didn't change the generation of trees themselves between 1.6 and 1.7).
ETA: I see you edited your post; that sounds like a good idea; another solution would be to mark the leaves as non-decaying until a block update occurs; currently, the game checks all leaves to see if they should decay and if not it sets a bit to indicate that no further checks are required, until a block update occurs; this isn't the same as player-placed leaves never decaying).
There is a bug report, but as I mentioned they were intentionally removed, so not really a bug (the real bug is whatever causes a huge performance drop in 1.7 when there are lots of decaying leaves, as I'm pretty sure they didn't change the generation of trees themselves between 1.6 and 1.7).
ETA: I see you edited your post; that sounds like a good idea; another solution would be to mark the leaves as non-decaying until a block update occurs; currently, the game checks all leaves to see if they should decay and if not it sets a bit to indicate that no further checks are required, until a block update occurs; this isn't the same as player-placed leaves never decaying).
Maybe an outside-inward decay system could alleviate the lag. Just put in the requirement for a leaf block to be bordered by three or more non-leaf blocks before it even attempts to decay (in addition to the normal requirements of having no wood within 4 blocks), instead of constantly re-checking, just to try and limit the amount that are attempting to decay simultaneously. It seems like the whole canopy would all eventually decay under those circumstances, just much slower. Or to even further simplify it, make it a bottom-up decay system. Like if all of the leaves on the lowest Y-layer of a tree must decay before any of the ones above it even attempt to decay. It could probably be done with a bit value per tree-associated leaf LAYER instead of a bit value per tree-associated leaf BLOCK.
They weren't removed entirely. They still generate in Extreme Hills and Ocean islands. Ice Plains too I think. Jeb most likely just removed them from forest because of how common they were and the lag they caused.
Instead of making large oaks progressively rarer in the 1.7 snapshots and find a good balance of performance and probability they get removed completely from forests without any middle ground? Yup, that sounds like Jens alright.
It's not a particularly good solution to make a boring, monotonous forest even more boring.
One thing to note about leaves - even if they don't actually decay there are still lots of chunk updates occurring because the game checks each leaf block to see if it needs to decay or not, then changes a metadata bit to disable further checks if it isn't set to decay, until a block update occurs; analyzing a freshly generated forest in MCEdit will show a large percentage of leaves as "decaying" even though most of them don't actually decay (a similar thing happens with water, which has flowing and stationary blocks; the flowing block isn't the same as visually flowing water and is normally only present in actively spreading water, if you place a stationary water block in the air it won't flow down until a neighboring block updates).
Thus, lag should mainly depend on the number of leaf blocks, not necessarily whether they are actually decaying or not. Also, there is still the matter of leaf decay apparently being far more resource intensive in 1.7, although people have complained of lag in jungles in earlier versions.
There is a bug report, but as I mentioned they were intentionally removed, so not really a bug (the real bug is whatever causes a huge performance drop in 1.7 when there are lots of decaying leaves, as I'm pretty sure they didn't change the generation of trees themselves between 1.6 and 1.7). ETA: I see you edited your post; that sounds like a good idea; another solution would be to mark the leaves as non-decaying until a block update occurs; currently, the game checks all leaves to see if they should decay and if not it sets a bit to indicate that no further checks are required, until a block update occurs; this isn't the same as player-placed leaves never decaying).
I posted it then realised how stupid it was and noticed there was no delete button (I'm new to the forums) and decided to edit over it.
Also
Lag is caused by the black spots and the top down lighting algorithm. Why remove the large oaks when the dark oaks and jungle trees are even worse? The large oaks were the best looking tree in the game.
You can get big oak trees by placing a oak sapling then placing a slab half a block above the sapling. and I have noticed that I've only seen 1 or 2 big oak trees since 1.7 came out.
I found a very simple solution to the leaf decay problem; basically, branches don't generate into leaf bunches, only connecting to the bottom, so the leaves at the top can decay. My solution simply adds in logs to extend the ends upwards and into the leaf bunches.
That is (my added code after the "Place 1-3 extra logs" comment, in WorldGenBigTree):
void generateLeaves()
{
int var1 = 0;
for (int var2 = this.leafNodes.length; var1 < var2; ++var1)
{
int var3 = this.leafNodes[var1][0];
int var4 = this.leafNodes[var1][1];
int var5 = this.leafNodes[var1][2];
this.generateLeafNode(var3, var4, var5);
// Places 1-3 extra logs to avoid leaf decay
// Checks for leaves above log to prevent logs from sticking out of the top
for (int y = var4 + 1; y <= var4 + 3; ++y)
{
if (this.worldObj.getBlockId(var3, y + 1, var5) == Block.leaves.blockID) this.setBlockAndMetadata(this.worldObj, var3, y, var5, Block.wood.blockID, 0);
}
}
}
Here's what my fix looks like with leaves removed; you can see the extra logs extending upwards from the ends of branches:
How effective is this? Here are a couple analyses of a Superflat world using a biome I made that exclusively contains big oak trees (averaging larger than usual, so more likely to have misplaced leaves):
After initial world generation:
After several minutes (chunk updates at 0):
(even after waiting several minutes there are still lots of "decaying" leaves due to being outside the chunk update radius; I simply analyzed the entire 400x400 block world)
If you add together the normal and "decaying" leaves both analyses come up with 529,673 leaves, with zero leaves actually decaying out of over 170,000 that changed over. Note that initially most of the leaves are marked as decaying, and in order to transition to non-decaying the game has to check every one of those half-million leaves to see if it is in a valid location, before updating the block to non-decaying (no further checks until a block update occurs) or destroy the block. Thus, to fix lag they should make it so the game simply doesn't bother to check for leaf decay on naturally generated leaves until a block update occurs.
(having said that, despite being in a forest entirely made up of big oak trees, I had no lag problems, this in 1.6.4, but 1.7+ no doubt would have gone into epileptic fits - due to poorly optimized code elsewhere, not the trees themselves, if 1.6.4 has no problems and tree generation was unchanged)
Large oaks no longer appear in the forest biome, but they still appear in the jungle and extreme hills biomes. I personally like the change for I can now cut down trees without the big trees getting in my way.
I'm finding them in jungle biomes--they're not always obviously oaks given the density of the trees there--but not really anywhere else. I do get them to grow from sapling on occasion though. But yes, I noticed this too because they're still very common in the Xbox 360 version.
If it's a bug, they should fix it. Big oaks are great part of the forest
I just looked through the wiki, and cannot find where it's stated; but I do recall reading about it.
Absolutely. They give forest biomes a sense of age, and they improve the landscape by breaking the monotony of all the other little 'lollipop' trees.
Nah, I'm talking about the larger oak trees, not giant jungle trees. http://minecraft.gamepedia.com/Tree
Now that really makes me think that it could be an unintentional change in the standard world generation algorithm.
I'd really like to know if it was an intentional change, or if it is a bug that needs to be reported. I really liked the big oaks.
They do grow on the sides of mountains in the extreme hills and I've seen them in ice plains too. I remember some changelog where they were removed too.
They were removed because of "lag", although instead of blaming the trees I'd blame other code in 1.7 for that (in 1.6 jungles are no problem for me; in 1.7 the game goes into fits as if it is going to crash any second when I enter one, taking a few minutes to stop lagging - no wonder they made them much rarer; at least the 1.8 snapshots seem better).
Not to mention, considering that they aren't that common, how would they have such a huge performance impact anyway (in the BiomeGenForest class in 1.6.4 there is a 20% chance of birch trees, then the other 80% are oaks, with 10% of those, or 8% overall, being large oaks)?
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Damn, if there was some sort of lag problem that came in around 1.7, maybe there may be a fix and they could reappear in 1.8?
So basically, I'm stupid.
There is a bug report, but as I mentioned they were intentionally removed, so not really a bug (the real bug is whatever causes a huge performance drop in 1.7 when there are lots of decaying leaves, as I'm pretty sure they didn't change the generation of trees themselves between 1.6 and 1.7).
ETA: I see you edited your post; that sounds like a good idea; another solution would be to mark the leaves as non-decaying until a block update occurs; currently, the game checks all leaves to see if they should decay and if not it sets a bit to indicate that no further checks are required, until a block update occurs; this isn't the same as player-placed leaves never decaying).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Maybe an outside-inward decay system could alleviate the lag. Just put in the requirement for a leaf block to be bordered by three or more non-leaf blocks before it even attempts to decay (in addition to the normal requirements of having no wood within 4 blocks), instead of constantly re-checking, just to try and limit the amount that are attempting to decay simultaneously. It seems like the whole canopy would all eventually decay under those circumstances, just much slower. Or to even further simplify it, make it a bottom-up decay system. Like if all of the leaves on the lowest Y-layer of a tree must decay before any of the ones above it even attempt to decay. It could probably be done with a bit value per tree-associated leaf LAYER instead of a bit value per tree-associated leaf BLOCK.
It's not a particularly good solution to make a boring, monotonous forest even more boring.
Thus, lag should mainly depend on the number of leaf blocks, not necessarily whether they are actually decaying or not. Also, there is still the matter of leaf decay apparently being far more resource intensive in 1.7, although people have complained of lag in jungles in earlier versions.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
I posted it then realised how stupid it was and noticed there was no delete button (I'm new to the forums) and decided to edit over it.
Also
Agreed
So basically, I'm stupid.
That is (my added code after the "Place 1-3 extra logs" comment, in WorldGenBigTree):
Here's what my fix looks like with leaves removed; you can see the extra logs extending upwards from the ends of branches:
How effective is this? Here are a couple analyses of a Superflat world using a biome I made that exclusively contains big oak trees (averaging larger than usual, so more likely to have misplaced leaves):
After initial world generation:
After several minutes (chunk updates at 0):
(even after waiting several minutes there are still lots of "decaying" leaves due to being outside the chunk update radius; I simply analyzed the entire 400x400 block world)
If you add together the normal and "decaying" leaves both analyses come up with 529,673 leaves, with zero leaves actually decaying out of over 170,000 that changed over. Note that initially most of the leaves are marked as decaying, and in order to transition to non-decaying the game has to check every one of those half-million leaves to see if it is in a valid location, before updating the block to non-decaying (no further checks until a block update occurs) or destroy the block. Thus, to fix lag they should make it so the game simply doesn't bother to check for leaf decay on naturally generated leaves until a block update occurs.
(having said that, despite being in a forest entirely made up of big oak trees, I had no lag problems, this in 1.6.4, but 1.7+ no doubt would have gone into epileptic fits - due to poorly optimized code elsewhere, not the trees themselves, if 1.6.4 has no problems and tree generation was unchanged)
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Praise be to Spode.
Formerly known as ORabbit around these parts.
So basically, I'm stupid.