[MC-10176] Oak/Dark Oak Tree Branches can replace all solid blocks (including Bedrock and Barrier) Created: 23/Feb/13  Updated: 02/Feb/21  Resolved: 16/Jan/15

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Snapshot 13w07a, Snapshot 13w09a, Snapshot 13w09b, Snapshot 13w11a, Minecraft 1.6.4, Minecraft 13w42b, Minecraft 13w43a, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 1.7.4, Minecraft 14w02b, Minecraft 14w02c, Minecraft 14w03a, Minecraft 14w03b, Minecraft 14w08a, Minecraft 1.7.5, Minecraft 14w10b, Minecraft 14w10c, Minecraft 14w11b, Minecraft 1.7.6-pre1, Minecraft 1.7.10, Minecraft 14w30c, Minecraft 14w31a, Minecraft 14w32d, Minecraft 14w33c, Minecraft 14w34a, Minecraft 14w34b, Minecraft 14w34c, Minecraft 14w34d, Minecraft 1.8, Minecraft 1.8.1-pre1, Minecraft 1.8.1-pre3, Minecraft 1.8.1
Fix Version/s: Minecraft 1.8.2-pre4

Type: Bug
Reporter: Michael Schiffner Assignee: Unassigned
Resolution: Fixed Votes: 31
Labels: None

Attachments: PNG File 2013-02-23_01.05.49.png     PNG File 2013-02-23_01.06.02.png     PNG File 2013-02-23_01.06.25.png     PNG File 2013-02-23_01.07.38.png     PNG File 2013-02-23_01.08.07.png     PNG File 2013-02-23_19.56.45.png     PNG File 2013-02-24_10.29.49.png     PNG File 2013-02-24_10.37.19.png     PNG File 2013-02-24_10.51.40.png     PNG File 2013-02-24_17.00.49.png    
Issue Links:
Duplicate
is duplicated by MC-39802 Dark oak saplings can break BEDROCK Resolved
is duplicated by MC-39994 Roofed Oak Tree grwoth can destroy bl... Resolved
is duplicated by MC-40091 Dark Oak roots can break bedrock on t... Resolved
is duplicated by MC-40289 Bed rock breaking Resolved
is duplicated by MC-40408 Dark Oak Position Bug Resolved
is duplicated by MC-40417 Replace Bedrock, "Brake" Bedrock, tre... Resolved
is duplicated by MC-40849 Break Bedrock Using Dark Oak Saplings Resolved
is duplicated by MC-42003 Trees (I think actual wood blocks not... Resolved
is duplicated by MC-42404 Glitch in Nether to get above the Bed... Resolved
is duplicated by MC-44478 Dark Oak Trees can replace unintended... Resolved
is duplicated by MC-44547 Tree branches' wood log blocks replac... Resolved
is duplicated by MC-46749 Growing Dark oak brakes barrier below Resolved
is duplicated by MC-49091 Dark Oak trees growing down can break... Resolved
is duplicated by MC-50137 Bedrock can be broken by dark oak trees Resolved
is duplicated by MC-63993 Sapling Bug. Resolved
is duplicated by MC-72843 Dark Oak breaks through bedrock Resolved
is duplicated by MC-75850 Leaves overwritting mushroom blocks Resolved
Relates
relates to MC-415 Leaves replace transparent blocks Resolved
relates to MC-2363 Leaves grow through walls Resolved
relates to MCPE-8094 Tree branches cut through blocks when... Resolved
CHK:
Confirmation Status: Confirmed
Game Mode: Creative

 Description   

To reproduce:

1 Build "tube" of any solid block as high as you want, with "open edges"

2 Plant sapling and grow it with bone meal.

3 Remove leaves to see, where wood replaced the solid blocks of the tube.

I suppose the kind of the solid block does not matter.



 Comments   
Comment by bob [ 20/Jan/15 ]

Sorry. It just didn't have the intermediate versions of the affects versions page and the comment confirming it had been fixed was:
Fixed in 1.8.2-pre4, possibly earlier.
Notice the 'possibly earlier'.

Comment by Kumasasa [ 20/Jan/15 ]

FM22, see at the top of this ticket, there is clearly written:

Status: Resolved
Resolution: Fixed
Fix Version/s: Minecraft 1.8.2-pre4

Comment by bob [ 20/Jan/15 ]

present in pre 3...
It was fixed in 1.8.2 PRE 4

Comment by bob [ 20/Jan/15 ]

present in pre 2...

Comment by bob [ 20/Jan/15 ]

present in pre 1...

Comment by bob [ 20/Jan/15 ]

Somehow, I dont think Mojang want to admit the version that has the bug fixed.

Comment by [Mod] redstonehelper [ 16/Jan/15 ]

Fixed in 1.8.2-pre4, possibly earlier.

Comment by [Mod] Pokechu22 [ 16/Jan/15 ]

This also occurs with 2x2 jungle trees if you have a 3 block padding.

██: bedrock
▒▒: any block on bottom layer; air on all others
▓▓: dirt/sapling/air depending on layer.

██ ██ ██ ██ ██ ██ ██ ██ ██ ██
██ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ██
██ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ██
██ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ██
██ ▒▒ ▒▒ ▒▒ ▓▓ ▓▓ ▒▒ ▒▒ ▒▒ ██
██ ▒▒ ▒▒ ▒▒ ▓▓ ▓▓ ▒▒ ▒▒ ▒▒ ██
██ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ██
██ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ██
██ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ▒▒ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██

With this structure bedrock in the walls will be replaced by wood in some of the jungle tree branches.

Comment by Fenhl (Max Dominik Weber) [ 07/Dec/14 ]

Affects 1.8.1, at least for dark oak.

Comment by [Mod] Torabi [ 25/Aug/14 ]

I don't think there's any legitimate reason to break blocks that are specifically designed to not be broken by the player. Bedrock and Barriers are there to give server admins or map creators a way of walling off sections of the world. It hurts gameplay or servers if they can't rely on that.

But really, I hope this gets fixed because it can break redstone machinery, most particularly automatic tree farms. Having a tree destroy your pistons or dispensers is a real pain.

Comment by Noproct [ 20/Aug/14 ]

In my opinion, breaking bedrock should be implemented as a feature, since it adds gameplay. Literaly 50% of the nether is not accessible without breaking bedrock. And it would be "unfair " towards players who haven't broken through bedrock in their world before it gets fixed.

Comment by Joey Sachtleben [ 11/Aug/14 ]

I found it with Jungle trees in 14w32d

Comment by Samuel Shank [ 06/Aug/14 ]

confirmed for 14w31a

Comment by Masahiro Kurokawa [ 29/Jul/14 ]

confirmed for 14w30c

Comment by Itouch2 [ 03/Apr/14 ]

Confirmed for 1.7.6pre

Comment by Adam Mercer [ 15/Mar/14 ]

Bug also appears in 14w11b.

Comment by Hafsteinn Már [ 07/Mar/14 ]

The same in Snapshot 14w10c

Comment by Galaxy_2Alex [ 04/Mar/14 ]

I opened the issue for the public as this issue is basically public due to many well-known Youtubers know it and used it publicly in their videos.
This might help to get attention to this bug to get this fixed. Yes, it is a very useful bug, but this is not supposed to be working like this.

Comment by fienxjox [ 19/Feb/14 ]

Still in 14w08a for dark oak

Comment by Anon Ymus [ 18/Mar/13 ]

Still in 13w11a.

Comment by Tails [ 18/Mar/13 ]

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.

Comment by Markku [ 28/Feb/13 ]

Affects 13w09b.

Comment by Markku [ 24/Feb/13 ]

Two bugs in the play.

Reason 1
At least for big (oak) tree generation, the method that checks whether a line of blocks is ok for generation has half-a-block difference compared to the method that later places the blocks. Thus, with (un)suitable angles, the checker slips through the corner, while the placer ends up stepping through the solid block.

Fix 1
Add the missing +0.5D's on the two minor axis. Using MCP and own namings, but should be clear where it is.

WorldGenBigTree.checkBlockLine()
    ...
    currentSpot[largestEndDeltaAxis] = from[largestEndDeltaAxis] + blockStep;
    currentSpot[axis2] = MathHelper.floor_double((double) from[axis2] + (double) blockStep * axis2Step + 0.5D);
    currentSpot[axis3] = MathHelper.floor_double((double) from[axis3] + (double) blockStep * axis3Step + 0.5D);
    ...

This should prevent the replacement of solid blocks, but does not prevent branches coming through the corners. But that is the next part...
(Also, the placer algorithm has unnecessary floor and +0.5 for the main axis; the base values are always integers so adding 0.5 and the taking the floor of it leads to the same base values.)

Reason 2
The "line tracing" method used is one that will only visit one block along each block size step in a direction where the slope of the path is smallest. Thus, it will "slip" through block corners.

Here is the code for the current algorithm (including the fix 1 from above):

WorldGenBigTree.checkBlockLine()
        ...
        int endMainCoord = endDelta[largestEndDeltaAxis] + mainStep;
        int mainCoord = 0;
        for (mainCoord = 0; mainCoord != endMainCoord; mainCoord += mainStep) {
            currentSpot[largestEndDeltaAxis] = from[largestEndDeltaAxis] + mainCoord;
            currentSpot[axis2] = MathHelper.floor_double((double) from[axis2] + (double) mainCoord * axis2Step + 0.5D);
            currentSpot[axis3] = MathHelper.floor_double((double) from[axis3] + (double) mainCoord * axis3Step + 0.5D);
            int blockId = this.worldObj.getBlockId(currentSpot[0], currentSpot[1], currentSpot[2]);
            if (blockId != 0 && blockId != Block.leaves.blockID)
                break;
        }
        ...

Fix 2 - partial
Replace the foor loop and add the method:

        ...
        do {
            // Point of entering the block:
            currentSpot[largestEndDeltaAxis] = from[largestEndDeltaAxis] + mainCoord;
            //              start point          + travel so far         - half a step
            double minor2 = (from[axis2] + 0.5D) + mainCoord * axis2Step - 0.5 * axis2Step;
            double minor3 = (from[axis3] + 0.5D) + mainCoord * axis3Step - 0.5 * axis3Step;
            currentSpot[axis2] = MathHelper.floor_double(minor2);
            currentSpot[axis3] = MathHelper.floor_double(minor3);
            
            // At the end?
            if (currentSpot[0] == to[0] && currentSpot[1] == to[1] && currentSpot[2] == to[2])
                break;
            
            if (!blockIsOk(currentSpot[0], currentSpot[1], currentSpot[2]))
                break;
            
            // Check minor axis at the point of leaving the block:
            //       start point          + travel so far         + half a step
            //double newminor2 = (from[axis2] + 0.5D) + mainCoord * axis2Step + 0.5 * axis2Step;
            //double newminor3 = (from[axis3] + 0.5D) + mainCoord * axis3Step + 0.5 * axis3Step;
            double newMinor2 = minor2 + mainStep * axis2Step;
            double newMinor3 = minor3 + mainStep * axis3Step;
            
            boolean change2 = MathHelper.floor_double(newMinor2) != currentSpot[axis2];
            boolean change3 = MathHelper.floor_double(newMinor3) != currentSpot[axis3];
            if (change2 && change3) { // Need to step along both minor axis
                // TODO: resolve in which order they should be stepped.
                currentSpot[axis2] = MathHelper.floor_double(newMinor2);
                if (!blockIsOk(currentSpot[0], currentSpot[1], currentSpot[2]))
                    break;
                
                currentSpot[axis3] = MathHelper.floor_double(newMinor3);
                if (!blockIsOk(currentSpot[0], currentSpot[1], currentSpot[2]))
                    break;
            } else if (change2) { // Need to step along axis 2
                currentSpot[axis2] = MathHelper.floor_double(newMinor2);
                if (!blockIsOk(currentSpot[0], currentSpot[1], currentSpot[2]))
                    break;
            } else if (change3) { // Need to step along axis 3
                currentSpot[axis3] = MathHelper.floor_double(newMinor3);
                if (!blockIsOk(currentSpot[0], currentSpot[1], currentSpot[2]))
                    break;
            }
            
            mainCoord += 1;
        } while (true);
        ...

    private boolean blockIsOk(int x, int y, int z) {
        int blockId = this.worldObj.getBlockId(x, y, z);
        if (blockId != 0 && blockId != Block.leaves.blockID)
            return false;
        return true;
    }

The loop is not fully optimized, but that is actually a minor thing compared to the fact that both the original and fixed version use double-values with absolute coordinates. This is bad coding, able to cause some issue at extreme coordinates. The algorithm should work on relative values (i.e. tree root would be always at values 0,0,0), which the block read and write routines would use by first taking 'floor' and then add the offset coordinates as integers.

If interested in how it works, I found a page that explains it quite well, although the above version is organized ever so slightly differently, and is for 3D instead of just 2D. http://sinepost.wordpress.com/2012/05/24/drawing-in-a-straight-line/

There is also that minor TODO-point left, but that only causes almost completely imperceptible difference with the "correct" operation.

NOTE: the same fix should NOT be applied to the placeBlockLine() method, otherwise branches will look, uh, twisted?

Remaining 'issues'
Note, this will only prevent branches sticking through the shown open-corner cylinder shapes. Just like some screenshots show with closed-corner cylinders, with this fix it is still possible to have those leaves-only growths outside the cylinder. This is yet another bug in the check routine; it only checks that the trunk has space to grow, not that there is a way for leaves to grow. Alternately, the generator could be a bit smarter when placing the leaves, but then it still allows rather silly trees (just the trunk and leaves on top of it).

Comment by Michael Schiffner [ 24/Feb/13 ]

Looks everytime like this with closed corners/edges.

Comment by Dean Baset [ 24/Feb/13 ]

The branches can also destroy bedrock!

Voting/

Comment by Anon Ymus [ 23/Feb/13 ]

Confirmed.

Generated at Sun Jan 12 12:23:30 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.