A 0-tick pulse is a redstone pulse, that turns on and off within one single game tick. This is possible, because block updates are calculated one at a time in a certain order, the block-update-order, even if they happen in the same game tick. To understand 0 tick technology one has to first acknowledge, that just because two things happen in the same game tick, they don't happen at once. There's always one thing happening first, and one thing happening second.
Problems with the block update order
For many blocks, the block update order will be location dependent, and therefore appear random to most human beings. But there are certain redstone triggered events, that reliably wait for almost all other blocks to update first, which can be used to compensate for the otherwise random update order. However it needs to be mentioned, that sometimes things in 0 tick technology can appear completely nonsensical and weird, because of the constant randomness introduced by the update order.
Why repeaters and comparators can be useful
Blue is input. Red block gets a 0 tick pulse output. This 0 tick generator was first discovered by test137e29.
Repeaters and comparators wait for almost all other redstone components to update first before they activate themselves. Additionally, comparators will always wait for all repeaters to update. Redstone components that wait a long time before updating are very helpful when making 0 tick pulse based contraptions. With repeaters
and comparators the following 0 tick generator can be made:
.
.
This 0 tick generator works in the following manner. When the lever is switched on, there will first be a 1 tick delay from both the repeater and the comparator. After that 1 tick delay the repeater and the comparator activate in the same game tick: First the repeater will update, because repeaters always activate before comparators. The output redstone will be powered by the repeater and anything connected to the red output block will also activate. The comparator will wait with updating until all the output redstone has been activated and the technical blocks connected to the output have also been updated. Only after the output redstone and the technical blocks connected to the output have been updated, the comparator will activate, and activate a piston, which will interrupt the redstone signal. Therefore the redstone dust connected to the output will have been activated and deactivated within 1 game tick. And almost all technical blocks connected to the redstone output will have had enough time to update, because comparators wait for such a long time in the update order.
Chaining repeaters and comparators
As previously mentioned, in each game tick first all repeaters will update, and afterwards all comparators will update. However there's still the following question: If two repeaters update within the same game tick, which one updates first? The answer to that question is: The repeater that first recieved its input one r-tick ago, will also output first. This makes repeaters and comparators even more useful, since the following things can be done:
If the lever on the picture on the right is flicked, the iron blocks, and technical blocks connected to them will update in the order, that is numerically shown on the picture. The blocks 1 and 2, will of course update before 3 and 4, because there are repeaters activating them, instead of comparators. However it is also guaranteed, that block 1 will activate before block 2, because the repeater that activates block 1 will be activated before the repeater that activates block 2, since the first repeater gets activated by a repeater, while the second repeater gets activated by a comparator. For similar reasons block 3 is also guaranteed to activate before block 4. It is even possible to make longer chains of repeaters and comparators to get more than just 4 updates in a reliable order.
Why retracting Pistons can be useful
A piston in a glitchy state.
This section is about 1.8 behavior and is accurate for 1.8. It has not yet been updated to 1.9.
When a piston is extended and gets deactivated, it does not instantly retract when it updates. When the piston first gets updated, it will transform into a glitchy state, which looks like this:
.
.
The piston will then wait for other blocks to update first, before the piston updates a second time, which will convert it to block 36, and which will also convert the block in front of the piston to block 36, if the piston is sticky. The 2 updates will happen within 1 game tick, but while the first update happens relatively early in the update order, the second update happens quite late and most other blocks including repeaters and comparators will update, before the second update of the piston retraction happens (This needs to be verified, even though Myrens is pretty sure, that this is correct, since 90% of his 0 tick technology is based on this assumption, and it works)
Since it takes such a long time, in terms of 0 tick delays, for a piston to retract, almost all piston based 0 tick pulse generators use piston retractions to interrupt a redstone signal. Examples would be the following 0 tick pulse generators:
.
A 0 tick pulse generator, that turns the signal off using a piston retraction. When the green wool (input) gets powered, after 1 redstone tick of delay, the red wool (output) recieves a 0 tick pulse.
In this 0 tick pulse generator the torch will turn off causing the piston to get into a glitchy state. The block in front of the piston will still be solid, while the piston is in the glitchy state. The repeater will then emit a redstone signal through the solid block to the output. The output redstone and most technical blocks connected to it will activate, while the piston is waiting in the glitchy state. Once everything connected to the output has activated the piston will update a second time, converting the block into block 36 and interrupting the redstone signal.
.
.
This is a pulse generator that directly powers a block, first shown by Defanive on YouTube. It also cuts the signal using a piston retraction, causing the 0 tick pulse to be long enough to make all technical blocks react to it, independent of direction or position.
In this 0 tick pulse generator the piston on top will first convert the redstone block into block 36. Unlike piston retractions, piston pushing happens relatively early in the block update order. After the redstone block is converted into block 36, the piston at the bottom will update and get into a glitchy state. Now all technical blocks connected to a potential output, will have time to update. After everything else has updated the piston at the bottom will start retracting the stone brick block, interrupting the signal. The 0 tick pulse part is now already complete. This contraption continues doing some other stuff, but that isn´t relevant to the 0 tick pulse generation.
These 0 tick pulse generators are widely used, because they generate comparatively long 0 tick pulses. The longer a 0 tick pulse is, the more technical blocks will react to it in a direction and location-independent way.
Multiple zero tick pulse generators may be chained, and if the generator uses redstone blocks, the signal may be taken using redstone dust. This was first shown by pi314159265358978.
Chaining (retracting) pistons
More information needs to be added.
.
.
.
Test137e29's weird piston effects (1.8 and earlier)
While a piston is in its glitchy state, the piston base is movable. This can be used to create the following, unexpected effects.
Pulling an extended piston:
If the lever on the picture is switched off, the piston on the left will be able to pull the piston on the right, even though the piston on the right is extended, and is supposed to be unmovable. This works in the following way:
.
.
When the lever is switched off, there will first be a one r-tick delay from the repeater and the comparator, before anything else happens. Then within one game tick the following updates happen:
.
.
.
First the repeater will turn off, because repeaters always update before comparators. This will cause the piston on the left to be converted into its glitchy state.
.
.
After that the comparator will turn off and the piston on the right will get converted into its glitchy state.
.
.
Now, since there's nothing else to update, the pistons, who are in the glitchy state, will start retracting. However, since the piston on the left transformed into its glitchy state first, it will also retract first (it is really surprising how inuitive and reliable the update order of piston retractions is). When the piston on the left retracts, it will try to pull the piston on the right, which is still in its glitchy state. Since the piston base of a piston in a glitchy state is movable, the piston on the left will successfully pull the piston on the right.
Pushing a piston, while it extends:
The comparator in the middle is actually unnecessary with this precise setup.
If a piston is given a zero-tick-pulse, the piston will be in a state very similar to the glitchy state, after the zero tick pulse turned off. The only difference will be, that there is not a piston head in front of him, but the block 36 of an extending piston head. In this other glitchy state, the piston base is also movable. The contraption on the right will use this to push and extend a piston at the same time. This results in a block 36 of an extending piston head, that is not connected to any piston. The block 36 will ignore the fact, that there is no piston base, but after 3 game ticks, once the block 36 turns into a piston head, the piston head will realize, that it has no piston base, and it will delete itself.
Pistons with multiple heads:
Creating a piston with two heads using comparator-repeater timings.
If a piston is moved, while it extends, and another piston is pushed in its position in less than 3 game ticks, then the piston head of the first piston will not delete itself, because it recognizes that it is connected to a piston base, without checking, whether that piston is facing in the same direction as the piston head. This means that one may get many strange configurations, such as pistons with multiple heads.
How Pistons react to 0 tick pulses
If a sticky piston gets converted from its glitchy state to its retracting state, while a block 36 that resulted out of a piston extension (and not retraction) is in front of the sticky piston, and if that block 36 moves in the direction the sticky piston is facing, then that block 36 will be instantly converted into its block form at its destination. What this practically means is, that if a sticky piston recieves a 1 tick pulse, the block in front of its face will finish its extension after one tick, instead of the usual 1.5 redstone ticks. What this means in relation to 0 tick pulses is, that if a sticky piston recieves a 0 tick pulses, the block in front of its face will finish its extension in 0 ticks, meaning it gets instnatly teleported. However this only applies to sticky pistons. If a normal piston recieves a 0 tick pulse, the block in front of its face will need 1.5 redstone ticks to travel to the next block.