Soni L.

both the reddit and the feedback website also consider it invalid, so if it's not a bug nor is it a feature request, wtf is it?

I'd expect the lava oceans of the nether to be water oceans in the overworld using the Caves buffet. so I don't think it makes sense.

Try reloading the world with the player in another chunk. If it works again, it has everything to do with that bug.

MC-144603

MC-144603

It's not just furnaces - chests stop making sound, and you get... "interesting" behaviour if you replace one of those "broken" furnaces with a chest.

The code-accurate description of the issue is that light-emitting blocks let light through, even if they're solid and their light level is much less than the light they're letting through.

MC-102162 is just a side-effect of the lighting update code not handling light-emitting blocks which emit less light than their in-world value. In other words, MC-102162 is caused by this issue.

Fixing MC-102162 doesn't fix this issue. On the other hand, fixing this issue would hide (but not technically fix) MC-102162.

The same applies to sunlight, as both sunlight and block light share most of the update code (NB: sunlight code also includes direct downwards propagation, which is the part that does not suffer from this issue - the solid blocks listed in this issue stop downwards propagation - however see MC-3961). The part that is shared uses a simple value to control which lightmap to access.

My current system setup is not capable of running multiple X sessions. Means I can no longer test this.

Hmm... OH!

Ok I didn't see that before. Player updates are actually done before block event processing. The fix might be to actually move player updates to after block event processing (together with entity and tile entity updates).

So currently you have player update -> redstone update -> block event queued -> block event processed, which makes it happen in the same tick. But for tile entity updates it only happens on the next tick. I think.

Doesn't explain pistons with a redstone block acting like players.

Ok so I figured out why it happens.

It has to do with this method in WorldServer:

private void sendQueuedBlockEvents()
    {
        while (!this.field_147490_S[this.blockEventCacheIndex].isEmpty())
        {
            int i = this.blockEventCacheIndex;
            this.blockEventCacheIndex ^= 1;

            for (BlockEventData blockeventdata : this.field_147490_S[i])
            {
                if (this.fireBlockEvent(blockeventdata))
                {
                    this.mcServer.getConfigurationManager().sendToAllNear((double)blockeventdata.getPosition().getX(), (double)blockeventdata.getPosition().getY(), (double)blockeventdata.getPosition().getZ(), 64.0D, this.provider.getDimensionId(), new S24PacketBlockAction(blockeventdata.getPosition(), blockeventdata.getBlock(), blockeventdata.getEventID(), blockeventdata.getEventParameter()));
                }
            }

            this.field_147490_S[i].clear();
        }
    }

I'm not entirely sure how it happens, but repeaters, pistons, note blocks and a few other blocks use them, and they are processed after every other processing that happens in the world, except entities and tile entities (which are also used by pistons, and the player is an entity).

I'm guessing it has something to do with entities and tile entities updating after block event processing. I'm guessing processing block events after entities and tile entities would fix it.

The levers attached to the piston with a redstone block activate the circuit the same as the bottom-most lever. From the repeater attached to that piston, the only lever which doesn't activate the circuit as expected is the one above the repeater (or, more specifically, the one east of the repeater).

This proves that the issue is specifically with repeaters. Pistons can be used to correct the repeater.

Why should they make no sound when placed? All blocks currently make sound when placed, even lilypads. (but only when they're placed on the side of a block)

Because pistons are buggy (hint: there are more piston-related bugs than anything else)

It's the behaviour when repeaters activate pistons that is wrong, stop trying to change that, I want my 20 TPS songs to be playable in survival Minecraft! (without the use of command blocks)

How do you explain this: http://youtu.be/TKSiNOuyYlw

eh guess I'll have to do this myself :/

Stick 2 repeater chains on the 2 outputs, all repeaters set to 1 tick, then do a slow motion video and you'll see one chain firing, then a delay, then the other, then another delay, etc so it can't be that.

That doesn't explain why a repeater chain keeps the proper timing offsets

This seems to have been fixed sometime between 14w31a and 1.8.1-pre3.

Attached "different" design. One of the levers activates the last piston, the other doesn't.