Jason Winzenried

@unknown'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

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.

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

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

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"

could we get some consistency please?

"Should your issue return please submit a new complete ticket with all available information."

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!

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)

deleterious effects, clear explanation, two character fix. six months old.

this bug tracker is useless

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.

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)

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

(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 🙂

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)

Mojang pls. I gave you two working code examples (and a pretty thorough explanation - at least read that) 😞

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:

public void updateEffects()
    {
        Iterator var8 = this.field_90038_c.iterator();

        while (var8.hasNext())
        {
            this.func_90037_b((EntityFX)var8.next());
        }

        this.field_90038_c.clear();
        
        for (int var1 = 0; var1 < 4; ++var1)
        {
            EntityFX var2 = null;

            try
            {
                for (int var3 = 0; var3 < this.fxLayers[var1].size(); ++var3)
                {
                    var2 = (EntityFX)this.fxLayers[var1].get(var3);
                    var2.onUpdate();

                    if (var2.isDead)
                    {
                        this.fxLayers[var1].remove(var3--);
                    }
                }
            }
            catch (Throwable var7)
            {
                CrashReport var4 = CrashReport.func_85055_a(var7, "Uncaught exception while ticking particles");
                CrashReportCategory var5 = var4.func_85058_a("Particle engine details");
                var5.addCrashSectionCallable("Last ticked particle", new CallableLastTickedParticle(this, var2));
                var5.addCrashSection("Texture index", Integer.valueOf(var1));
                throw new ReportedException(var4);
            }
        }
    }

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,

public EntityFX(World par1World, double par2, double par4, double par6, double par8, double par10, double par12)
    {
        super(par1World);
        this.setSize(0.2F, 0.2F);
        this.yOffset = this.height / 2.0F;
        this.setPosition(par2, par4, par6);
        this.prevPosX = par2;
        this.prevPosY = par4;
        this.prevPosZ = par6;

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