MC-11208The big tree generator handles tree height variable incorrectly
(Relates to MC-10534 and MC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)
(Using MCP namings.)
The WorldGenBigTree has instance variable heightLimit. The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 times 11), etc. etc.
(Edit: ) Note also that the trees are created somewhat "next to next" per location, the same height of trees can be noticed in the world, as many nearby big trees have the same height, then another bunch has another height shared between them, etc.
Fix?
public boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...
Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b, 1.5-pre. (Can not check the code for the latest (only the trees/world), though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)
Created Issue:
The big tree generator handles tree height variable incorrectly
(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable "heightLimit". The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 of 11), etc. etc.Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b. (Can not check the code though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)
(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable "heightLimit". The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10of11), etc. etc.Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b. (Can not check the code though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable "heightLimit". The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 times 11), etc. etc.Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b. (Can not check the code though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)
(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable "heightLimit". The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 times 11), etc. etc.(Edit
Note also that the trees are created somewhat "next to next" per location, the same height of trees can be noticed in the world, as many nearby big trees have the same height, then another bunch has another height shared between them, etc.
Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b. (Can not check the code though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)
(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable "heightLimit". The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 times 11), etc. etc.(Edit
Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b. (Can not check the code though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable "heightLimit". The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 times 11), etc. etc.(Edit: ) Note also that the trees are created somewhat "next to next" per location, the same height of trees can be noticed in the world, as many nearby big trees have the same height, then another bunch has another height shared between them, etc.
Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b. (Can not check the code though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)
is duplicated by
(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable "heightLimit". The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 times 11), etc. etc.(Edit: ) Note also that the trees are created somewhat "next to next" per location, the same height of trees can be noticed in the world, as many nearby big trees have the same height, then another bunch has another height shared between them, etc.
Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b, 1.5-pre. (Can not check the code for the latest (only the trees/world), though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)
relates to
This ticket is incomplete without the requested information, no response has been received within a reasonable time. If you are still experiencing this issue, we can reopen it at your request.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
relates to
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable "heightLimit". The same generator instance is used to create many trees during world generation. However, that heightLimitvariable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 times 11), etc. etc.(Edit: ) Note also that the trees are created somewhat "next to next" per location, the same height of trees can be noticed in the world, as many nearby big trees have the same height, then another bunch has another height shared between them, etc.
Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b, 1.5-pre. (Can not check the code for the latest (only the trees/world), though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)(Relates to
MC-10534andMC-2759; doesn't fix them, but perhaps makes the effects of the feature less noticeable.)(Using MCP namings.)
The WorldGenBigTree has instance variable heightLimit. The same generator instance is used to create many trees during world generation. However, that heightLimit variable is only written to at few occasions; initialization to 0, randomized when it is zero, and when tree height (free space) check deems it needs to be shorter. Thus, the start of world generation can look like this (for tree heights):
0 -> 10, 10, 10, 10, 10, .. (30 more of 10) .., 7, 7, 7, 7, 7, 10, 10, 10, (10 more of 10), ... (occasional streak of 10 times 11), etc. etc.(Edit: ) Note also that the trees are created somewhat "next to next" per location, the same height of trees can be noticed in the world, as many nearby big trees have the same height, then another bunch has another height shared between them, etc.
Fix?
WorldGenBigTreepublic boolean generate(World world, Random random, int x, int y, int z) { ... // FIX? Remove this check. //if (this.heightLimit == 0) { this.heightLimit = 5 + this.rand.nextInt(this.heightLimitLimit); //} if (!this.validTreeLocation()) { return false; } ...Tested on 1.4.7 and nice random heights from tree to tree, no sequences of same height observable.
Since the generated worlds from the same seed (from
MC-10534) look exactly the same (including the pair of two small "bigtrees"), this affects also all the way to 13w10b, 1.5-pre. (Can not check the code for the latest (only the trees/world), though, but would be quite the miracle if this bug wasn't there, yet produced same trees.)
ProfMobius (Thomas Guimbretiere)Big Oak Trees completely fail to generate in Forest, Flower Forest, etc ...
This bug seems worse than MC-11208 since big trees doesn't even attempt to generate, instead of being generated weirdly
In jungle biomes, however, they are replaced by trees with generical spherical foliage
Steps to reproduce :
_Find a Biome in which Oak Trees can spawn naturally
_Notice how Big Oak Trees are missing
Alternate way :
_Create a superflat world of a Forest for exemple with decorations enabled
_Notice how Big Oak Trees are missing
Turns out it's a so-called "FPS fix" by [Mojang] Jeb (Jens Bergensten)
http://www.reddit.com/r/Minecraft/comments/1m97cw/while_you_are_all_crying_over_the_name_change_of/
The reason they got removed was because they don't follow the leaf decay rules, and thus caused a LOT of chunk updates. I basically doubled my FPS in forests by removing these.
My intention was not to remove them completely, though, but rather "fix them later". The problem now is that the code for those trees is super-complex, and not the easiest thing to work with.
Problem description: Leaves must be placed so they are connected via other leaves to a tree trunk, max 4 steps away. Where's the bug?
...
BigTree source code from Jeb: big_tree.java
Paul Spooner, original maker of Forester Filter and gave the Big Tree generation code to Notch, says:
The stuff you're looking for is in the "foliageShape" function. I suggest replacing the line:
else if ((y == 0) || (y == (foliageHeight - 1))) return (float) 2;with the following two lines
else if ((y == 0) || (y == (foliageHeight - 2))) return (float) 2; else if (y == (foliageHeight - 1)) return (float) 1.5;The change should reduce the size of the foliage clusters and prevent decay.
Hm... could be intentional, but we don't know exactly. Allthough, this is still a Duplicate of MC-11208, possibly with another reason.
Afaik, there are both intentional and non-intentional differences. See MC-29844 (mentions intentional "temporary" change) and MC-11208 (definitely unintentional one). Also, naturally, each tree is generated (sapling or world creation) with randomness to both size and shape. The description of this issue leaves me scratching head if either of those might be behind this one or not.
I mean once the game is opened, no matter which world i create, all of the big oak trees generated are all the same(one type of the 3 showed in the pictures).But when I close the game and restart it, the type of big oak trees may be changed to another kind, but all of the trees are still the same.
In Version 1.10 this problem still occurs.
The problem may be linked to MC-11208, i think.
The world generation in 1.6.2 still matches the
MC-10534screenshot (which was generated with bugged version), and code seems to look the same (at least the proposed fix part, didn't check the whole class), so I assume it is still not fixed. Added the version to affects-list.Due to having
MC-29844around, and no access to code (i.e. MCP for latest versions) to check for sure, it is not possible check the status of this issue and update the affected version for now (except for Mojang coders, of course). That said, I have not seen any big trees by world generation in latest versions (both 1.7.5 and snapshots), so either this orMC-29844or both are still in effect.Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. If this has been done, we can reopen the issue.
Keep in mind that the "Resolved"-Status on this ticket just means "Answered", and that we are waiting for further information on whether this issue still exists or not. We will reopen it as soon as the requested information has been deliviered.
No response for over a year.
Confirmed using MCP 9.31 for Minecraft 1.10, and creating new worlds in the current snapshot certainly seems to display the behavior of large numbers of big oak trees with the same height.
After some testing I found out that it also changes every time you open any world for the first time after restarting the game and it stays the same for all the others until a new restart. I can't read the code so I can't confirm it in any technical way. However, one can recreate it by:
1) Create a new world that has a forest biome nearby
2) Wait for the chunks to load
3) Restart the game
4) Open the world and go to previously ungenerated chunks
5) See how large oak tree generation has changed (May not work if the variable randomizes to the same number)
Still an issue in 16w39c.
Still an issue in 16w40a.