[MC-7508] lighting error due to Chunk.heightMap ignoring block at the top level of an ExtendedBlockStorage instance (off by 1 error) Created: 15/Jan/13 Updated: 12/Jun/16 Resolved: 18/Jul/14 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Minecraft 1.4.6, Minecraft 1.4.7, Snapshot 13w02b, Snapshot 13w05b, Minecraft 1.5, Minecraft 1.5.1, Minecraft 1.5.2, Minecraft 1.6, Minecraft 1.6.1, Minecraft 1.6.4, Minecraft 13w38c, Minecraft 1.7.5, Minecraft 14w11b, Minecraft 14w26c, Minecraft 1.7.10, Minecraft 14w28b, Minecraft 14w29a |
| Fix Version/s: | Minecraft 14w30a |
| Type: | Bug | ||
| Reporter: | Jason Winzenried | Assignee: | [Mojang] Searge (Michael Stoyke) |
| Resolution: | Fixed | Votes: | 34 |
| Labels: | block, rendering, world | ||
| Environment: |
java 7 64 bit, win server 2008 r2 |
||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Community Consensus | ||||||||||||||||||||||||||||||||||||
| Description |
|
REPRODUCE CONFIRM FROM SCRATCH THE CAUSE int var1 = this.getTopFilledSegment(); 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; 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: |
| Comments |
| Comment by kazblox [ 05/Aug/14 ] |
|
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. |
| Comment by Marcus Lorenzen [ 24/Jul/14 ] |
|
It is not fixed, look at https://www.youtube.com/watch?v=VAht6IisnQw and |
| Comment by user-f2760 (Inactive) [ 24/Jul/14 ] |
|
it is fixed in the snapshot of 1.8.... so it's fixed in 1.8.... |
| Comment by Marcus Lorenzen [ 24/Jul/14 ] |
|
Thank you, and can you please test the bug and set it to confirmed? |
| Comment by Kumasasa [ 24/Jul/14 ] |
|
Ok. |
| Comment by Marcus Lorenzen [ 24/Jul/14 ] |
|
|
| Comment by Kumasasa [ 23/Jul/14 ] |
|
Please make a new ticket. |
| Comment by Matt Kelliher [ 23/Jul/14 ] |
|
Can a mod please clarify: should this be re-opened or a new ticket submitted for the newly introduced bug that supposedly fixed this one? |
| Comment by Marcus Lorenzen [ 23/Jul/14 ] |
|
The fix flips the Bug to the upper Side. |
| Comment by Matt Kelliher [ 16/Jul/14 ] |
|
14w29a is affected too. Can a mod please update the affected versions? |
| Comment by Matt Kelliher [ 11/Jul/14 ] |
|
Went back and confirmed with 14w28a as well. |
| Comment by Matt Kelliher [ 11/Jul/14 ] |
|
Confirmed this is still happening with 14w28b using "CONFIRM FROM SCRATCH" instructions. I used flat terrain and built 3 platforms - one at Y=30, Y=31, and Y=32. Platform built at Y level 31, when re-loaded, has the shadow disappear when walking over top of the shadow on the ground. (Shadow stays for platforms at Y=30 and Y=32) |
| Comment by Marcus Lorenzen [ 10/Jul/14 ] |
|
Thank you. |
| Comment by Kumasasa [ 28/Jun/14 ] |
|
Derp. Will test later. |
| Comment by Marcus Lorenzen [ 28/Jun/14 ] |
|
Follow the "REPRODUCE:" or "CONFIRM FROM SCRATCH:" |
| Comment by Kumasasa [ 28/Jun/14 ] |
|
How to test ? |
| Comment by Marcus Lorenzen [ 28/Jun/14 ] |
|
Still happening on Launcher version 1.4.4 and MC Version 1.7.10 + 14w26c. |
| Comment by Deleted account [ 25/May/14 ] |
|
Is this still a concern in the current Minecraft version 14w21b / Launcher version 1.4.4 or later? 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 [Mod] Ezekiel (ezfe) [ 20/Mar/14 ] |
|
Jason, actually that wording has since been removed, it was incorrect. We now use
|
| Comment by Talven81 [ 20/Mar/14 ] |
|
The reason that is posted is in many cases a reply after the ticket has been closed may not be noticed if a moderator is not actively watching the queue. However I was, and your ticket was reopened. |
| Comment by Jason Winzenried [ 20/Mar/14 ] |
|
of course, I was far to broad in my usage of "you". Of course you can't do anything about it. I wish someone would though! So yeah I slacked off on checking (I've been keeping it up for a while, as you will notice from the post date + list of affected versions). 1.7.2 to 1.7.5 wasn't really a large enough change to prompt me to check again. I've done so now, and with the latest snapshot, and it is still there. I do wish you would get your story straight between "Should your issue return please submit a new complete ticket with all available information." and "Please do not clone existing tickets" |
| Comment by Talven81 [ 20/Mar/14 ] |
|
I'm sorry updating affected versions once every few months to ensure the bug is known to exist in current versions is too much effort, however you reported the bug and I can't say that an additional 15 seconds of your time every few months is too much to ask. Frequently bug reports go stale because the user abandons them, or the issue is fixed by another patch and the user abandons the ticket without informing us it has been fixed. Updating the affected versions ensures the ticket stays alive. We are moderators not Mojang employees, we cannot change the code. |
| Comment by Jason Winzenried [ 20/Mar/14 ] |
|
yes it's still an issue. How can you expect me to check this report every few months when none of you** can take a second to change two characters in the codebase and fix it? How much effort am I supposed to expend on this? **I unfairly directed this ire towards the moderators. Sorry! |
| Comment by [Mod] Ezekiel (ezfe) [ 11/Jan/14 ] |
|
This ticket is incomplete without the requested information, no response has been received within a reasonable time and we are assuming the issue has been resolved. Should your issue return please submit a new complete ticket with all available information. |
| Comment by Talven81 [ 26/Nov/13 ] |
|
Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.3.4 ? 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 Jason Winzenried [ 24/Sep/13 ] |
|
still present in 1.6.4 and 1.7pre REPRODUCE: 1: load this world: http://www.mediafire.com/?8o5hj55pwjolwos confirm from scratch |
| Comment by Markku [ 10/Jul/13 ] |
|
Source code seems to have this bug still in 1.6.2, but I seem to be unable to reproduce this (or |
| Comment by [Mod] Ezekiel (ezfe) [ 10/Jul/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 Jason Winzenried [ 04/Jul/13 ] |
|
deleterious effects, clear explanation, two character fix. six months old. this bug tracker is useless |
| Comment by Code Raider [ 16/Apr/13 ] |
|
This bug is not related to |
| Comment by Jason Winzenried [ 14/Feb/13 ] |
|
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. |
| Comment by Jonathan Levasseur [ 06/Feb/13 ] |
|
"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. |
| Comment by Oscar Parker [ 17/Jan/13 ] |
|
So to clarify, this is caused by the subtraction (to get 0-based index from 1-based index) happening twice, at So removing either offending subtraction would fix it. |
| Comment by Kumasasa [ 15/Jan/13 ] |
|
Steps to reproduce (see
|
| Comment by Jason Winzenried [ 15/Jan/13 ] |
|
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) |