Affects Version/s: Snapshot 13w03a, Snapshot 13w04a, Snapshot 13w09a, Snapshot 13w09b, Snapshot 13w10b, Minecraft 1.5, Snapshot 13w11a, Minecraft 1.5.1, Minecraft 1.7.4, Minecraft 14w02c, Minecraft 14w03b, Minecraft 14w04a, Minecraft 14w04b, Minecraft 14w05a, Minecraft 14w05b, Minecraft 14w08a, Minecraft 1.8.8, Minecraft 15w47c, Minecraft 15w51b, Minecraft 16w02a, Minecraft 1.9, Minecraft 1.9.1 Pre-Release 3, Minecraft 1.9.2, Minecraft 1.9.3 Pre-Release 2, Minecraft 1.9.3 Pre-Release 3, Minecraft 1.9.4, Minecraft 16w20a, Minecraft 16w21a, Minecraft 16w21b, Minecraft 1.10 Pre-Release 1, Minecraft 1.10 Pre-Release 2, Minecraft 1.10, Minecraft 1.10.1, Minecraft 1.10.2, Minecraft 16w40a, Minecraft 16w41a, Minecraft 16w44a, Minecraft 1.11 Pre-Release 1, Minecraft 1.11, Minecraft 1.11.2, Minecraft 17w06a, Minecraft 1.12.1 Pre-Release 1, Minecraft 1.13.2, Minecraft 19w02a, 1.15.2, 20w07a, 20w19a, 1.16 Pre-release 8, 1.16 Release Candidate 1, 1.16, 1.16.1, 1.16.2 Pre-release 1, 1.16.2 Pre-release 2, 1.16.2 Release Candidate 1, 1.16.2, 1.16.3 Release Candidate 1, 1.16.3, 1.16.4 Pre-release 2, 1.16.4, 20w46a, 20w49a, 20w51a, 1.17, 1.17.1 Release Candidate 1, 1.17.1
Fix Version/s: Snapshot 13w09c
Category:Block states, Redstone
When a piston receives a 0 tick redstone signal it pulses instead of staying in the current state. Before 1.3.1 pistons would turn into derp pistons but now they pulse which is equally annoying. It destroys piston based logic (most importantly instant logic).
It is pretty easy to recreate this bug: Just connect a input with a 1 tick delay (repeater) and the inverted input (1 redstone torch = 1 tick delay) to a piston and switch the state of the input.
For pistons this bug is still not completely fixed because when receiving a 0 tick redstone signal from other pistons (e.g. in instant logic) a piston will still pulse sometimes depending on how the redstone gets updated.
Edit, 16-MAR-2016: It would be really nice if 0-tick/micro pulses (or as Dico has correctly said years ago, non-existing pulses in Minecraft terms) would finally be patched out of the game and if the game was able to handle actual simultaneity. So a proper/intelligent block update algorithm with a consistently synced quantized timeline instead of random Java hashsets and micro time-intervals, which would allow multiple blocks (that interact with eachother) to be updated all in the same gametick into their correct new stages (instead of purely successive block updates which leads to wrong/unintended behaviour).
To replicate it, OR the input of an instant NOT gate (http://youtu.be/vCsJWc7PcT0) and it's output together and attach it to another piston. Toggle the input and the piston will pulse even though it shouldn't. It usually only happens on the falling edge (lever going from on to off) because the block that gets pulled by the piston (and by that allows a new connection to a powersource) gets updated after the line of redstone that is directly connect to the lever, which leads to a combined output that pulses for a split second. It does not affect all positions/placements because of the location dependent nature of block updates in Minecraft.
With the use of instant ALUs, we could build 5Hz CPUs (maybe with small games running on it) and other very cool things but this completely illogical bug doesn't seem to get the attention it needs.
I suggest a server command / gamerule to switch between the current (unintended) behaviour and the fixed/intended behaviour so that contraptions of people using microticks can remain working.
More info in the last few comments.