Jason Winzenried
- mamiyaotaru
- mamiyaotaru
- Europe/Stockholm
- Yes
- No
MC-7508![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
haha ok. That's something then. It worked nicely in 1.4.4, I'll have a look at 1.4.5 just as soon as Searge works his magic. Working on different codebases is rough
*one download later* and yeah, it is there in 1.4.5. It categorically was not in 1.4.4 with my fix (I'd invite you to stick the class in a 1.4.4 jar and see). Not sure if it translated to the real codebase correctly. Like I said, will know more in a day or so
Chunk.heightMap ignores block at the top level of an ExtendedBlockStorage instance (off by 1 error)
Chunk.heightMap ignores block at the top level of an ExtendedBlockStorage instance (off by 1 error) - lighting glitch
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:
int var5 = this.getBlockID(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 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)
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 causes lighting glitches. If a flat single block roof is built at level 15 or 31 or 63 (etc) that roof is ignored in the heightmap, and thus in lighting. Areas below will be fully lit even without torches, as the sunlight passes right through the blocks that heightmap knows nothing of. See screenshots.
lightbug3.png
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:
int var5 = this.getBlockID(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
checkthis.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)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 causes lighting glitches. If a flat single block roof is built at level 15 or 31 or 63 (etc) that roof is ignored in the heightmap, and thus in lighting. Areas below will be fully lit even without torches, as the sunlight passes right through the blocks that heightmap knows nothing of. See screenshots.
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 belowCONFIRM 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 and my previous report ( https://bugs.mojang.com/browse/MC-7508 ) was closed because I didn't diligently check every month to update which version it applied to, as though it would magically fix itself despite the code not changing.
IMAGES ATTACHED:
visual explanation of bug, and shot of bug in action
Chunk.heightMap ignoresblock at the top level of an ExtendedBlockStorage instance (off by 1 error)- lighting glitchlighting error due to Chunk.heightMap ignoring block at the top level of an ExtendedBlockStorage instance (off by 1 error)
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 belowCONFIRM 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
and my previous report (https://bugs.mojang.com/browse/MC-7508) was closed because I didn't diligently check every month to update which version it applied to, as though it would magically fix itself despite the code not changing.IMAGES ATTACHED:
visual explanation of bug, and shot of bug in actionREPRODUCE:
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 belowCONFIRM 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
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 belowCONFIRM 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
checkthis.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 and my previous report ( https://bugs.mojang.com/browse/MC-7508 ) was closed because I didn't diligently check every month to update which version it applied to, as though it would magically fix itself despite the code not changing.
IMAGES ATTACHED:
visual explanation of bug, and shot of bug in actionREPRODUCE:
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 belowCONFIRM 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 and my previous report ( https://bugs.mojang.com/browse/MC-7508 ) was closed because I didn't diligently check every month to update which version it applied to, as though it would magically fix itself despite the code not changing.
IMAGES ATTACHED:
visual explanation of bug, and shot of bug in action
this is due to a change in EffectRenderer.java (MCP name. all names and code below will be from MCP - necessitated by obfuscation. I'd love to post this fix with the real class, method and variable names)
I've got a one class mod that fixes it here: http://www.planetminecraft.com/mod/fix-ghost-torch-flicker-144/
EXPLANATION:
OK, in EffectRenderer, addEffect(EntityFX par1EntityFX) used to add the entity to EffectRenderer.fxLayers[]. Now addEffect adds the Entity to ArrayList field_90038_c.
In updateEffects(), that ArrayList is iterated through, and each new entity is added to fxLayers[] as before. The problem is this happens after fxLayers is iterated through, and all of the entities have their onUpdate() called.
So, onUpdate() is called for every FX entity (except the new ones), wherein their prevPosX/Y/Z is set to posX/Y/Z. Only then are the new ones added to the list, so that when EntityRenderer.renderWorld(float par1, long par2) calls EffectRenderer.renderParticles(var4, par1), all of the newly added entities still have their prevPosX/Y/Z set to 0 (ZERO).
This causes an issue in EntityFX.renderParticle() with lines like
float var13 = (float)(this.prevPosX + (this.posX - this.prevPosX) * (double)par2 - interpPosX);
prevPosX is a spurious 0, and the entity is rendered in the wrong location (for one tick) before it gets updated like it should with all the older entities.
FIX:
in EffectRenderer.updateEffects(), add the new entities before calling each entity's onUpdate(). Basically make the method look like this:
ALTERNATIVELY:
set each entity's prevPosX/Y/Z to posX/Y/Z on creation. Then you can skip updating whatever new entities you want.
in EntityFX.java,
should do the trick
SERIOUSLY THOUGH:
why, in a bugfix release, would you do something like this. 1.4.4 should have fixed the blockers in 1.4.3 and nothing else, not making unrelated changes like what caused this. Going forward a real bugfix release would be more like a release including only this change (to fix the torches) without touching anything else. Put out 1.4.4a and save other changes for the next version (1.5 maybe)
SPECULATION:
were you getting concurrent access violations with fxLayers? ie could addEffects() be called from a different thread than updateEffects() - changing the List while it was being iterated through? If not ignore the following
Your new way of adding to a temporary holding List fixes that, though now you would have the possibility of Concurrent Access Violations on field_90038_c (a smaller possibility granted, since you spend less time going through it adding new entities than you do updating all the old ones). You'd really need to Lock the List for the duration of the loop. Adding the new holding List would make that less painful, since like I mentioned before you spend less time there. It's just stuffed up by running the update loop before the add loop.
If it has nothing to do with multithreading weirdness, I have no idea why that intermediate holding List for adding entities is there instead of just sticking them in directly as before. No one owes me an explanation but I'd love to hear why that change was made
Mojang pls. I gave you two working code examples (and a pretty thorough explanation - at least read that)
well, I put my 1.4.4 fixed azf.class in the 1.4.5 jar and they are gone again (they were definitely there in vanilla 1.4.5).
Something got lost in the translation between codebases. I'll have a look when Searge updates, but it would be nicer to be on the same page
to reiterate: http://www.planetminecraft.com/mod/fix-ghost-torch-flicker-144/ works in 1.4.5 as well (though I'd really rather retire it haha)
(regarding TorchTest.zip and azf.class attachments) stand at 1120, -1955. look across the torches towards 0,0. Set Performance to Power Saver to slow things down a bit. Observe as new flame sprites warp in from 0,0 to their correct spot. Try again with my azf.class in place
I'm a little sad to see they (not quite correctly) implemented my second fix. The first one feels much more "correct" while the second was sort of a hacky workaround if they didn't feel like doing the first for whatever reason. Much better IMHO to add the new entities before the update loop.
I will second the difficulty added to their job by having to translate from MCP. I'm not really a fan of the obfuscation in this instance
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)
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.
deleterious effects, clear explanation, two character fix. six months old.
this bug tracker is useless
still present in 1.6.4 and 1.7pre
REPRODUCE:
1: load this world: 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 in the initial report.
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)
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!
could we get some consistency please?
"Should your issue return please submit a new complete ticket with all available information."
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"
please implement this. After literally hours of forceupgrade, any newly visited (but already existing) chunk lags a lot to load. It's nice to convert all the blockdata or whatever at one go, but it would be awesome to be able to do so with lighting as well. It's just as slow visiting new chunks as before I ran forceupgrade
this is the same bug as https://bugs.mojang.com/browse/MC-179858
worlds from before 20w17a have their heightmaps messed up when loaded in 20w17a. Can see with f3 the S and M values (for WORLD_SURFACE and MOTION_BLOCKING) are just completely random values. A world newly created with the new snapshot does not show this issue
this is indeed the same bug as "underground rain" as seen at https://bugs.mojang.com/browse/MC-180090 and probably others
worlds from before 20w17a have their heightmaps messed up when loaded in 20w17a. Can see with f3: the S and M values (for WORLD_SURFACE and MOTION_BLOCKING) are just completely random values. A world newly created with the new snapshot does not show this issue for me.
JellySquid's resource pack reduces my GPU usage to 67% of what it was before applying it. Not noticed any downsides to it. geforce 2060 super