Inconsistency between repeaters/activated torches and buttons/levers/player-placed torches/redstone blocks/pistons activating redstone devices

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

Reopened, thanks.

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

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.

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

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

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)

Is this still an issue in the current Minecraft Snapshot 15w46a 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.

I think the explanation in this bug report is incorrect.

The difference between a user input and a repeater input is that a repeater input lets a second repeater have a 2 game-tick delay, while a user input causes it to have a 1 game-tick delay. This is because user actions are processed before anything else (including increasing the world tick count).

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.

The bottom two levers act the same because they are both directly connected to the same redstone.

The one that activates a repeater, then the rest of the circuit causes the piston to be extended in 2 game ticks, and the repeaters to be extended in 2 game ticks as well.

The one that activates a repeater, then a piston, and then the rest of the circuit, causes the second piston to be extended in 3 game ticks. The repeaters are still turned on after 2 game ticks.

Therefore, I would expect the bottom piston to extend later when the left most repeater is powered first compared to when the top most repeater is powered first.

When the redstone is directly powered, the top piston should extend sooner than both of these cases, since the piston will then be extended in 2 game ticks, while the repeater will be extended in 1 game tick.

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.

It happens because user events are processed before the world tick is increased. The world tick is also what is used by pistons/repeaters and everything. This is also what is used if you want to create a door that can only be opened by a player standing on a pressure plate for example.

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

What you have there is a lot of bugs in one picture. Lets look at it not as bugs, but as the way the game works(which is pretty much the case anyway):

Piston powering piston(via converting block 36): the second piston has a 3gtick delay before it is extended.
Player powering piston: the piston has a 2 gtick delay before it is extended.
Repeater/comparator powering piston: the piston has a 2 gtick delay before it is extended.

Piston powering repeater: the repeater has a 2 gtick delay.
Player powering repeater: the repeater has a 1 gtick delay.
Repeater/comparator powering repeater: the second repeater has a 2 gtick delay.

If something should be happening in the same gametick, it comes down to update order, which is way more complicated still.

If you want to know exactly what happens when and why, take a look at the videos in this post: https://www.reddit.com/r/technicalminecraft/comments/39d013/the_precise_timings_of_repeaters_pistons_and/

It can take a few hours to understand it though, but the basics is what I explained above.

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.

Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time.

Can confirm for 1.12