REPRODUCE
1: load the attached world (mirrored at http://www.mediafire.com/?8o5hj55pwjolwos )
2: walk under the platform. Watch the shadow disappear. This only happens with platforms at level 15, 31, 47, 63, etc, for the reasons described below
CONFIRM FROM SCRATCH
1: start a flat world.
2: Build a large 1 block thick platform at y level 31 (or 15 or 63)
3: exit.
4: Load world again. walk on the ground under the platform. Shadow from the platform disappears as the lighting is updated based on the heightmap (which does not see the platform)
THE CAUSE
Chunk.java has an error in the generation of heightMap (an int[256] ) in the method public void generateHeightMap().
int var1 = this.getTopFilledSegment();
returns the highest ExtendedBlockStorage with a block in it.
inside the x and z loops (from 0 to 16), for each x-z coordinate the method establishes the highest block with opacity > 0.
int var4 = var1 + 16 - 1;
starts us at the top of the ExtendedBlockStorage returned earlier, then it loops down to find the first block with opacity > 0.
The problem is an off by one error. The blocks that are checked are retrieved like so: Block var5 = this.func_150810_a(var2, var4 - 1, var3);
the "var4 - 1" is the problem. The top block is ignored / never checked.
If the top two blocks are solid, the heightmap is set to the height of the lower one. If the top block is solid, then the next four are air then the next is solid, the height map is set to 5 below the top block.
The method either needs to start checking at this.getTopFilledSegment() + 16 instead of this.getTopFilledSegment() + 16 - 1, or inside the loop check this.func_150810_a(var2, var4, var3) instead of this.func_150810_a(var2, var4 - 1, var3)
This bug (and related) is likely the cause of some of the lighting glitches seen. See attached image for a visual representation of this report. Also, all variables, classes and method names are from MCP. I of course do not have access to your internal codebase. Hopefully you can translate.
This bug has been around sine 1.8 BETA Please kill it π
IMAGES ATTACHED:
visual explanation of bug, and shot of bug in action
Linked issues
is duplicated by 2
relates to 4
Attachments
Comments 35
Steps to reproduce (see MC-7442 ):
Create a superflat world (Preset Overworld)
Dig a tunnel 1 block below the surface
So to clarify, this is caused by the subtraction (to get 0-based index from 1-based index) happening twice, atint var4 = var1 + 16 *- 1*;
andint var5 = this.getBlockID(var2, var4 *- 1*, var3);
So removing either offending subtraction would fix it.
"The method either needs to check this.getTopFilledSegment() + 16 instead of this.getTopFilledSegment() + 16 - 1, or inside the loop check this.getBlockID(var2, var4, var3) instead of this.getBlockID(var2, var4 - 1, var3)" Quote from Jason Winzenried
So I tested your theory and guess what...It works, it got rid of the light bug! All I did was remove the -1 from the line "this.getBlockID(var2, var4 - 1, var3)" hopefully the team of Mojang will have a closer look at this part of the code and see what is going on there. I don't want to keep on removing that silly little number all the time when the game updates. π
part of me wants to just wait and see if this gets fixed along with Dinnerbone's lighting changes. At the same time, as long as he is doing that, I'd love to be sure this actually gets addressed. This bug has been around since 1.8 beta at least.
Thank you, and can you please test the bug and set it to confirmed?
So we maybe can get it fixed before 1.8
It is not fixed, look at https://www.youtube.com/watch?v=VAht6IisnQw and MC-63346
Parts of it were unfixed due to certain trees not generating... https://twitter.com/SeargeDP/status/492316809115086848 I can confirm that it's back, but shows up obscurely.
JIRA should have a "Partially Fixed" field for these kinds of bugs.
lighting errors as a result of the heightmap ignoring y levels 31 and 63 (as it does for every level that's at the top of an ExtendedBlockStorage)