Kwin van der Veen

The following video gives idea of what causes this bug: https://www.youtube.com/watch?v=qEi-tKrxDNk

It basically is due to the fact that minecraft does not check the area above hoppers for entities when a block is placed on top which has an inventory. So since a brewing stand has an inventory, this means that hoppers do not try to detect whether there are entities above it and only tries to pull items out of the brewing stand instead.

You are not able to give yourself a stack of 64 of non-stackable items anymore, however it is still possible to get signals greater then 15 by using command blocks and testfor entities.

The first 3 repeaters in your video seem to follow the same cycle, however to moment of placing might have given the offset of the phase.
However I do have a video in which the a similar phenomenon in demonstrated at the beginning: in certain positions 50% of the off-pulses get ignored.

This is an duplicate of MC-11193.

I can also confirm that this bug still exists in Minecraft 1.5.1.

This is caused by the "spaces" within the arguments, so "/testfor @p
[score_Kills_min=1,score_dummyName_min=1]" would probably work.

I think the problem here isn't the comparator, but the repeater. This pulse (when you have redstone wire instead of the repeater) will probably also be also be able to toggle torches for 1 tick.

What is the bug? Since to me it seems that it is working as intended, a comparator (either in compare or subtract mode) have the same amount of delay as a repeater at default timing, so 1 redstone tick, which is equal to 2 game ticks.

I can't confirm this in 1.5.1. When I tested it it always had a 1 tick gap.

I can confirm this as well in 1.5.1. It seems to happen to all the entities, so far I have tested: minecarts, boats and a few mobs. I think it is caused by an incorrect viewing frustum culling.

I just did some tests with other "block updates", since in a certain way it does make sense that a (trap)door which has been put into a "bad" state by a player would change to the "right" state when receiving a block update.

There are some inconsistencies. When I open an unpowered (trap)door (so by a player) it will close again if there is a redstone block update, but not if there are other block updates like placing/removing a block. But when it is the other way around, so when I close a powered (trap)door it will open again with any block update.

I was doing some tests with 1 tick pulses. And it seems that 1 tick pulses which do trigger comparators, will keep being able to trigger them if this signal is extended by comparators. However once you extend this pulse once by a repeater it won't trigger comparators again. These 1 tick pulses also trigger torches, however 1 tick pulses from torched do not always trigger comparators.

If a bug would make an double piston extender more compact, doesn't mean it is consistent with the rest of the logic of the game.
And this compact double piston extension is also heavily direction dependent and inconsistent as demonstrated in this short video: http://www.youtube.com/watch?v=_eqsc5Q3cko

So I would really hope that this would either be removed or be made much more consistent.

This also affects 13w10a (but not any snapshots before it), hopefully this helps figuring out what is causing this.

I also noticed this bug today and made video about it (since I though it hadn't been posted): http://www.youtube.com/watch?v=KM9DNfxBogw

A possible way which might fix this would be fist to check the all arguments of all the command blocks which are activated in the same tick to determine which command should be executed and then execute theses commands.

This seems to be fixed in 13w10b. So dispensers and droppers both get triggered by 1 tick pulses and 1 tick clocks (2 ticks cycle), however a comparator clock only triggers them once if they are placed to close to the output of the comparator. I haven't tested good enough, but it seems that the dropper or dispenser has to be more than 2 blocks away from the block in front of comparator to get triggered multiple times.

I just noticed something, if you right click the comparator while being powered (so it would toggle between compare and subtract mode) then the repeater does show that it is locked. Tested this in snapshot 13w06a. However if I reload the world/chunk will reset this and no block update seems the trigger this as well.

This works as intended. Because a repeater will delay the signal, but also extend it to its delay length if the input is shorter. So the 2 tick pulses from the clock will be turned into 4 tick pulses, which will overlap the 2 ticks the clock is outputting a low signal.

The strange this is that this bug only occurs when a dropper puts an item into a hopper. A comparator does update its output if another hopper would transfer an item into the hopper (throwing an item into the hopper would trigger it as well). And replacing the hopper by any other block (or entity) with an inventory (chest, furnace, dropper, dispenser, hopper, minecart with chest/hopper) does update the comparator when a dropper would drop an item into it.

But you shouldn't rely on game mechanics which are implemented in snapshots. And if you want a small 1 tick pulse generator (on the rising edge) you could use this: http://imgur.com/kSz9idp