Vincent Wiltschek
- vin97
- vin97
- Europe/Stockholm
- Yes
- No
MC-7441
Normal
MCPE-15391
Low
MCPE-15392
[13w02b] Sticky Piston Pulse Bug - Signal Strength Combinations.txt
I know that one is not supposed to write this in a bug report but I have to make the point clear:
It is extremely important that this bug gets fixed because currently all redstone circuits/contraptions that use sticky pistons are broken or at least don't work properly.
Especially now that we've got the opportunity to create sticky piston based instant logic gates without the usage of any bugs like before, it is quite annoying that this ruins all of it.When a sticky piston is powered and the signal strength of the redstone attached to it changes, the sticky piston pulses (contracts for a short time and then extends again) even though it should stay extended all the time.
But this does not happen everytime, it depends on how the signal strength changes. I've gone through all possible ways to change the signal strength and created a list where all 47 combinations of before (old) and after (new) signal strength values are listed that cause the sticky piston to pulse.
I tried my best to find a rule and created a little algorithm that tells you for every new signal strength value which old signal strength values would cause the sticky piston to pulse. This algorithm still has 5 exceptions and does not make any sense at all. This brought me to the conclusion that this definetely has to be a bug.
Since these combinations are so random, it is basically impossible to build a redstone circuit with sticky pistons and avoid this bug from happening.
You would have to place the redstone so that no matter what the situation is, the change in signal strenth in front of any piston included in the ciruit would not be one of the listed combinations.I attached a .txt file with the list and my pseudo code (algorithm).
Me and the complete redstone community hope that this bug gets fixed before Minecraft 1.5 will be released!
I know that one is not supposed to write this in a bug report but I have to make the point clear:
It is extremely important that this bug gets fixed because currently all redstone circuits/contraptions that use sticky pistons are broken or at least don't work properly.
Especially now that we've got the opportunity to create sticky piston based instant logic gates without the usage of any bugs like before, it is quite annoying that this ruins all of it.When a sticky piston is powered and the signal strength of the redstone attached to it changes, the sticky piston pulses (contracts for a short time and then extends again) even though it should stay extended all the time.
But this does not happen everytime, it depends on how the signal strength changes. I've gone through all possible ways to change the signal strength and created a list where all 47 combinations of before (old) and after (new) signal strength values are listed that cause the sticky piston to pulse.
I tried my best to find a rule and created a little algorithm that tells you for every new signal strength value which old signal strength values would cause the sticky piston to pulse. This algorithm still has 5 exceptions and does not make any sense at all. This brought me to the conclusion that this definetely has to be a bug.
Since these combinations are so random, it is basically impossible to build a redstone circuit with sticky pistons and avoid this bug from happening.
You would have to place the redstone so that no matter what the situation is, the change in signal strenth in front of any piston included in the ciruit would not be one of the listed combinations.I attached a .txt file with the list and my pseudo code (algorithm).
Me and the complete redstone community hope that this bug gets fixed before Minecraft 1.5 will be released!
EDIT EDIT EDIT
It actually IS a randomly occuring bug. There is no way to know exactly when the sticky piston pulses in every situation.
That makes building redstone circuits with sticky pistons trial and error. So it's even more important that it will be fixed.
When you unlock a 1-tick-repeater for 1 tick, it won't change it's state.
For some strange reason a 2-tick-repeater will change states correctly when attached to a 1-clock.DELETE
Repeater not unlocking properly when unlocked for 1 tickDELETE
DELETE
When a 1-tick-repeater gets unlocked for 1 tick it doesn't change it's state (no matter what the input is).
For some strange reason, a 2-tick-repeater will change states correctly when permanently locked and unlocked by a 1-clock.
DELETERepeater not unlocking properly when unlocked for 1 tick
Update issues with repeater locks causing wrong pulsing
Repeater lockscan cause monostable circuits (pulses) that should not existRepeater locks incorrectly pulse under certain conditions (due to inconsistent block updates)
When the input of a repeater and the repeater that is locking the first repeater are turned off at the same time, the first repeater will pulse on for a time period equal to it's delay creating a falling edge monostable circuit which should not
work.When the input of a repeater and the repeater that is locking the first repeater are turned off at the same time, the first repeater will pulse on for a time period equal to it's delay creating a falling edge monostable circuit which should not be possible.
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.This bug is only fixed partially for pistons that receive a 0 tick off pulse from a repeater, comparator or a torch.
If you create a 0 tick off pulse with pistons (e.g. by using instant logic) pistons will still pulse (in 1.5.1)!!!
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.This bug is only fixed partially for pistons that receive a 0 tick off pulse from a repeater, comparator or a torch.
If you create a 0 tick off pulse with pistons (e.g. by using instant logic) pistons will still pulse (in 1.5.1)!!!
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.Update 1.5.1:
Even 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.
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.Update 1.5.1:
Even 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: To make it clear,
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.Update 1.5.1:
Even 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: To make it clear,
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.Update 1.5.1:
Even 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 pulses (or as Dico has correctly said years ago, non-existing pulses) would finally be patched out of the game.
To replicate it, OR the input of an instant NOT gate (youtu.be/vCsJWc7PcT0) and it's output together and attach it to another piston. Switch the input on and off and the piston will pulse even though it shouldn't. It does not affect all positions/placements because of the random nature of Minecraft's block update 'algorithm'.
With the use of instant ALUs, we could build 5Hz CPUs and other very cool things but this completely completely illogical doesn't seem to get the attention it needs.
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.Update 1.5.1:
Even 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 pulses (or as Dico has correctly said years ago, non-existing pulses) would finally be patched out of the game.
To replicate it, OR the input of an instant NOT gate (youtu.be/vCsJWc7PcT0) and it's output together and attach it to another piston.Switchthe inputon and offand the piston will pulse even though it shouldn't. It does not affect all positions/placements because of the random nature of Minecraft's block update 'algorithm'.
With the use of instant ALUs, we could build 5Hz CPUs and other very cool things but this completely completely illogical doesn't seem to get the attention it needs.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.Update 1.5.1:
Even 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 pulses (or as Dico has correctly said years ago, non-existing pulses) would finally be patched out of the game.
To replicate it, OR the input of an instant NOT gate (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 does not affect all positions/placements because of the random nature of Minecraft's block update 'algorithm'.
With the use of instant ALUs, we could build 5Hz CPUs and other very cool things but this completely completely illogical doesn't seem to get the attention it needs.
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.Update 1.5.1:
Even 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 pulses (or as Dico has correctly said years ago, non-existing pulses) would finally be patched out of the game.
To replicate it, OR the input of an instant NOT gate (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 does not affect all positions/placements because of the random nature of Minecraft's block update 'algorithm'.
With the use of instant ALUs, we could build 5Hz CPUs and other very cool things but this completelycompletelyillogical doesn't seem to get the attention it needs.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.Update 1.5.1:
Even 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 pulses (or as Dico has correctly said years ago, non-existing pulses) would finally be patched out of the game.
To replicate it, OR the input of an instant NOT gate (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 does not affect all positions/placements because of the random nature of Minecraft's block update 'algorithm'.
With the use of instant ALUs, we could build 5Hz CPUs and other very cool things but this completely illogical bug doesn't seem to get the attention it needs.
Powered mechanisms react when receiving a 0 tick redstone signal (existence of 0-tick pulses in general)
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.Update 1.5.1:
Even 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 pulses (or as Dico has correctly said years ago, non-existing pulses) would finally be patched out of the game.
To replicate it, OR the input of an instant NOT gate (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 does not affect all positions/placements because of the random nature of Minecraft's block update 'algorithm'.
With the use of instant ALUs, we could build 5Hz CPUs 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.
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.Update 1.5.1:
Even 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 pulses (or as Dico has correctly said years ago, non-existing pulses) would finally be patched out of the game.
To replicate it, OR the input of an instant NOT gate (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 does not affect all positions/placements because of therandomnature of Minecraft's block update 'algorithm'.
With the use of instant ALUs, we could build 5Hz CPUs 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.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.Update 1.5.1:
Even 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 instead of random Java hashsets).
To replicate it, OR the input of an instant NOT gate (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 does not affect all positions/placements because of the location dependent nature of Minecraft's block update 'algorithm'.
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.
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.Update 1.5.1:
Even 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 quantized time instead of random Java hashsets and micro time-intervals).
To replicate it, OR the input of an instant NOT gate (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 does not affect all positions/placements because of the location dependent nature of Minecraft's block update 'algorithm'.
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.
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.Update 1.5.1:
Even 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 quantized time instead of random Java hashsets and micro time-intervals).
To replicate it, OR the input of an instant NOT gate (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 does not affect all positions/placements because of the location dependent nature ofMinecraft's block update 'algorithm'.
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.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.Update 1.5.1:
Even 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 quantized time instead of random Java hashsets and micro time-intervals).
To replicate it, OR the input of an instant NOT gate (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 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.
Powered mechanisms react when receiving a 0 tick redstone signal (existence of 0-tick pulses in general / random block update 'algorithm')
Powered mechanisms react when receiving a 0 tick redstone signal (existence of 0-tick pulses in general /randomblock update 'algorithm')Powered mechanisms react when receiving a 0 tick redstone signal (existence of 0-tick pulses in general / incosistent block update 'algorithm')
Powered mechanisms react when receiving a 0 tick redstone signal (existence of0-tickpulses in general / incosistent block update 'algorithm')Powered mechanisms react when receiving a 0 tick redstone signal (existence of micro-pulses in general / incosistent block update 'algorithm')
Powered mechanisms react when receiving a 0 tick redstone signal (existence of micro-pulses in general / inconsistent block update 'algorithm')
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.Update 1.5.1:
Even 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 quantized time instead of random Java hashsets and micro time-intervals).
To replicate it, OR the input of an instant NOT gate (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 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.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.Update 1.5.1:
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 quantized time instead of random Java hashsets and micro time-intervals).
To replicate it, OR the input of an instant NOT gate (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 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.
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.Update 1.5.1:
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 quantized timeline instead of random Java hashsets and micro time-intervals).
To replicate it, OR the input of an instant NOT gate (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 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.
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.Update 1.5.1:
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 quantized timeline instead of random Java hashsets and micro time-intervals).
To replicate it, OR the input of an instant NOT gate (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 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.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.Update 1.5.1:
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 quantized timeline instead of random Java hashsets and micro time-intervals).
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 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.
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.Update 1.5.1:
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 quantized timeline instead of random Java hashsets and micro time-intervals).
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 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.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.Update 1.5.1:
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 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.
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.Update 1.5.1:
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 happens only on the falling edge (lever going from on to off) because the block that gets pulled by the piston (and by that creates a 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 secodn. 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.
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.Update 1.5.1:
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 happens only on the falling edge (lever going from on to off) because the block that gets pulled by the piston (and by that creates 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 secodn. 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.
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.Update 1.5.1:
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 happens only on the falling edge (lever going from on to off) because the block that gets pulled by the piston (and by that creates 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 secodn. 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.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.Update 1.5.1:
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 happens only on the falling edge (lever going from on to off) because the block that gets pulled by the piston (and by that creates 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.
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.Update 1.5.1:
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 happensonlyon the falling edge (lever going from on to off) because the block that gets pulled by the piston (and by that creates 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.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.Update 1.5.1:
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 only usually happens on the falling edge (lever going from on to off) because the block that gets pulled by the piston (and by that creates 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.
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.Update 1.5.1:
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. Itonlyusually happens on the falling edge (lever going from on to off) because the block that gets pulled by the piston (and by that creates 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.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.Update 1.5.1:
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 creates 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.
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.Update 1.5.1:
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 thatcreates 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.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.Update 1.5.1:
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.
Same as in Minecraft.
Same as in Minecraft, so also related to
MCPE-15391(https://bugs.mojang.com/browse/MCPE-15391).
Same as in Minecraft, so also related to
MCPE-15391(https://bugs.mojang.com/browse/MCPE-15391).Same as in Minecraft (MC-9955), so also related to
MCPE-15391(MC-8328).
[Copy of MC-9955] Repeater locks incorrectly pulse under certain conditions (due to inconsistent block updates)Please delete - made a mistake
Same as in Minecraft ( MC-9955 ), so also related to
MCPE-15391( MC-8328 )........ deleted.....
Exactly the same as in Minecraft.
Please code a proper block update (order) algorithm!Exactly the same as in Minecraft (MC-8328).
Please code a proper block update (order) algorithm!
Exactly the same as in Minecraft ( MC-8328 ).
Please code a proper block update (order) algorithm!Exactly the same as in Minecraft ( MC-8328 ), so also related to
MCPE-15392( MC-9955 ).Please code a proper block update (order) algorithm!
Exactly the same as in Minecraft (MC-8328), so also related to
MCPE-15392(MC-9955).Please code a proper block update (order) algorithm!
@Vincent Wiltschek: Please use the preview feature when editing something - you're flooding 20 people with every edit attempt.
Vincent Wiltschek That test is impossible to perform, as MCPE pistons have different timings from Java edition pistons and therefore an instant NOT gate cannot be constructed. See MCPE-15607. I am currently investigating this issue, though. There IS definitely some odd timing stuff going on with MCPE redstone, though I'm not sure 0-ticking is one of those things. Keep in mind that MCPE redstone is programmed VERY differently from the Java edition, and seemingly similar problems may be causes by very different things in each edition.
You are right but I've found out the details and how to reproduce it.
Found out the details and how to reproduce it:
MC-7441Well in 13w03a it's still not fixed.
Yes, I know it's a special case of the old update bug. But since they are currently fixing these bugs (especially those related to pistons) I wanted to make sure that they know about this one.
Awesome, so it will just be a texture bug?
Why is it incomplete?
Why is it marked as resolved? Could you reopen it?
Not that the bug is that important, I'd rather see MC-8328 fixed.
It is.
Why? It affects every version until it gets resolved. Simple logic.
No point in creating a list of 20 different versions.
Ok, this bug is an exception then because it is most probably caused by MC-8328 (0-tick pulses) that in turn seems to be caused by the fundamentally illogical block update 'algorithm' of Minecraft that is unable to properly handle simultaneity.
If there is one bug that won't get fixed 'accidentally' it's MC-8328 (and therefore MC-9955, too).
0-tick pulses are not what makes instant logic possible. It purely has to do with the moved block instantly becoming transparent (which is completely intended behaviour).
I know that there are some other instant repeater designs out there that somehow use microticks but they are unnecessarily complex and obviously even more unreliable.
I understand that there are a lot of applications for 0-tick pulses but unlike quasi connectivity (or other "accepted bugs") they completely destroys basic logic (in other applications).
Minecraft time is designed to be quantized and the smallest interval is supposed to be 0.05s.
Therefore, Minecraft should also be able to handle simultaneity, it cannot do that at the moment.
If you want to actively bypass these design principles and you need micro-intervals to get something to work, it should not make other ("legit") contraptions impossible/unreliable, especially when these contraptions will lead to much more advanced technologies than piston doors (just imagine what you could do with a 5Hz CPU!).
...My suggestion would be a gamerule that can turn micropulses on or off so that everybody is happy.
Well, we were actually talking about the same repeater designs and I really don't see where they rely on microticks (time intervals below 0.05s).
I had some different ones in mind when you mentioned microticks but I cannot remember where I saw them.
They DO completely destroy basic logic because when a piston stops receiving power and starts receiving power from a different powersource in the same gametick, it pulses.
In other words, you will have a moment where you will see the piston retracting although the redstone line was always ON!!
"As I also mentioned, it is very possible to make instant logic work right now."
Nope, not reliably. Build an instant adder and test all possible input transitions, even better, do it at operation speed (5Hz).
Of course, I'm happy to be proved wrong.
"You have to synchronize the incoming signals to solve that"
They are synced to the shortest consistent time unit of Minecraft (1 game tick).
"Apply logical thinking instead of requesting a change that makes it easier."
I'm ignoring this since you could say the same thing about builds that rely on micropulses if the situation was the other way around.
"Mojang made pistons work this way, they weren't designed to do the things they do entirely, indeed, but right now, as with diagonal powering it is too late to revert this change IMO."
"My last point: Why should we remove an awesome aspect of the game for the bigger player base (timing-centered redstoners) to make some other thing with logic-centered redstone easier?"
Once again, you are not losing anything if Mojang introduces a (server) command that can switch between the unintended and intended behaviour. There does not have to be a trade-off.
"That's not a nice trade-off."
That's your opinion.
...Maybe think about what could be done with CPUs that are more than 50 times faster than anything that has been created in Minecraft.
"Fixing" 0 tick pulses (meaning removing them where possible) is not illogical, it simply requires an actual algorithm to decide the block update order instead of just relying on random java hashsets!
Good example, Myren. The problem with the circuit you posted is not pistons reacting to 0-tick pulses but the fact that you built an instant/infinite feedback loop (basically the grandfather paradox).
There is no why any game or simulation could handle this situation correctly. In this case, you cannot avoid pulses (I mean you could just make it so that nothing is happening at all but I agree with you that this is probably not the best solution).
In every other case (where the order of events can be logically/causally assigned) 0-tick pulses can be removed.
The piston flip flops you are talking about, Dico, do not require 0-tick pulses. They work the same way with 1 (redstone) tick pulses.
And hopefully for the last time, I suggest a command that lets you decide what type of behaviour you want so that all of your circuits can remain working.
Yes, I am criticizing the random block updates and their consequences, which are 0-tick pulses because Minecaft does not update blocks in sync.
The problem is not necessarily the update order but the lack of a "buffer", meaning that Minecraft should wait until the next gametick to put all affected blocks into the next state at the same time instead of reacting successively in microintervals (whether it be to user inputs or circuit outputs). The update ordering/processing should all be done "internally" instead of directly influencing in-game behaviour.
To be clear, I am not talking about "making 0-tick pulses reliable/intuitive", so removing the direction/position dependencies and other inconsistencies. I AM talking about completely removing them from the game because a proper update algorithm does not require them...
Now, I have to say that I didn't consider instant feedback loops like the ones you posted but realize that in these cases there simply is no logical behaviour because what is supposed to happen is impossible: Due to the instant properties of pistons, the redstone should be simultaneously on and off. Saying "the piston should pulse" is just as legit in this situation as saying "nothing should happen", as is saying "the piston should turn into a derp piston".
Thank you for taking this a step further by comparing the piston inside the loop to an "external piston" and showing how there would be inconsistencies if you used micropulses in some situations as solutions to impossible tasks and got rid of them in other situations.
Because letting nothing happen even though the switch changed state doesn't make sense and because not allowing a switch to be toggled would be strange (and because inconsistencies are to be avoided), my conclusion on instant feedback loops is: The internal piston(s) should turn into derp piston(s) (lock in the current state) and the external one(s) should therefore do nothing. All this does not require micropulses.
I will add my suggestion of a server command to my original bug report, consequently the monostables you posted would not work with the "intended behaviour" option (no 0-tick pulses whatsoever), while everything remains as it is with the "unintended behaviour" option (this being the default setting).
EDIT: How pistons behave when they are retracting is completely off-topic. We are basically discussing whether or not pistons (or other mechanisms) should start retracting (in these 'special' cases) in the first place.
you could always add another server command lol
but no, I agree with you, since these feedback loops can only be used for creating pulses (not logic or any function that could get destroyed), it would be better to let them pulse.
Hold on, let me do another check.
Sorry, the bug does NOT exist in PE/Windows 10.
I made a mistake.
You can delete this issue.
Yes, exactly.
Sorry for the duplicate but I could not select "Minecraft Pocket Edition" or "Minecraft for Win10" in the list of affected versions of the original issue.
If you could add it to the list for me, you could delete this duplicate issue right here.
The bug has been discussed intensively in the comments section of the original issue (the conclusion is in the original report).
Also affects Minecraft Pocket/Win10 Edition v0.15.0 (
MCPE-15391).Ok but this bug right here definitely does not exist in the Pocket/Win7 Edition.
oops, sorry.
didn't know you get a notification for every edit.
I gave one way to replicate it in the description of MC-8328.
Still the same. Bug not solved.
Please test the bug with pistons as described in my initial report (MC-8328):
"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"
Did you read the last part of the description?
Read the last edit. It explains a way to replicate the bug without torches. Just instant NOT gates using pistons and repeaters.
The problem ARE 0tick pulses off pulses.
Would really like to see a working 6.7Hz CPU but I don't see how that is possible with 0tick pulses going off randomly everwhere.