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, 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 the same time. 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 is location dependent, and therefore can appear random. But there are certain redstone-triggered events that reliably wait for almost all other blocks to update first. This can be used to compensate for the seemingly random update order. However, it needs to be mentioned that sometimes things in 0-tick technology can appear nonsensical and weird because of this randomness introduced by the update order.
Why tiletick priorities are useful[]
Blue is input. Red block gets a 0 tick pulse output. This 0 tick generator was first discovered by test137e29.
Repeaters and comparators update in the tiletick phase of a gametick, which means they tend to fire earlier in a gametick compared to purely piston-based 0-tick generators. Comparators will also (almost) always update after repeaters, meaning that one can guarantee one-line outputs before another by using a repeater on the line which needs to update first and then using a comparator to update the line that needs to output later.
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 they have a lower tiletick priority than comparators. The output redstone will be powered by the repeater, and anything connected to the red output block will power and schedule their own tileticks or block events. The comparator will wait with updating until all the output redstone that has been activated by the repeater has been updated. Only after everything connected to the repeater is resolved, 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. Almost all redstone components, with the exception of pistons that would have been powered by quasi-connectivity, will react to this 0-tick pulse as the difference in tile tick priority will make sure the output reacts before the piston inside the 0-tick generator.
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 received its input one 2 ticks 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 block event order is useful[]
A piston in a glitchy state.
When a piston is extended and gets deactivated and updated, it will schedule a block event at the end of the list of block events, and the piston will not start retracting until it's block event has been processed. Piston block events can cause other pistons to schedule block events, which will be placed end of the list, so one can manipulate the order in which block events are scheduled to have a power source being removed after the power source is activated in the gametick.
A piston will wait for earlier phases of a gametick, such as tileticks, and earlier block events to process before its block event has been processed. When a piston's block event is been executed, it will turn itself, and if extending or if it's a sticky piston scheduled to retract, the block in front of it into block 36. Block 36 can not output redstone signals and also cannot cut redstone lines, so redstone component can be powered by uncutting a redstone dust line, or a power source can be removed by turning the block which is powering a redstone source or allowing a connection between a power source and the output into block 36.
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 redstone dust will power the solid block, as well as updating any blocks within the redstone dust update range, scheduling tileticks and/or block events connected to the output, as well as scheduling a block event for a piston on top. All tileticks will execute and then the block event stage will happen. The piston on top will then start extending, which will turn the redstone block into block 36, which causes the bottom piston to be unpowered as well as updating the bottom piston. This will schedule a block event for the bottom piston to retract at the end of the list. When the bottom piston's block event executes, it will start retracting, which will remove the power source from the top piston as well as update the top piston, which will schedule a retraction block event at the end of the list. When the top piston's block event is executed, the piston immediately finishes its extension and start retracting, causing the redstone block to instantly drop. This device will do other stuff following this, but they are irrelevant in regards to 0-tick pulse generation.
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 pistons[]
Because piston block events are always added to the end the list, pistons. The goal of chaining pistons in a 0-tick generator is to execute extension block events before the power source is removed, or retraction block events before the power source is added, because if a scheduled piston block is executed, but the power source is inconsistent with what the block event it trying to do, the piston will not respond to it. Although there is no such thing as block event groups, it can be useful to think of piston block events being in groups. Block events scheduled by tileticks, player inputs, or the entity phase of the previous gametick can be thought of in a first group, and block events scheduled by group 1 block events can be considered in group 2, and block events scheduled by group 2 block events can be considered in group 3, and so on. The order of any block events in a group is based on when block events are determined based on the order in which they were scheduled, so one must take care when using redstone dust as it is locational. Scheduling the block event which changes the power source in a group after which the block events in the output are scheduled will make sure any 0-tick build is non-locational.
The 0-tick generator pictured to the right makes use of piston update chains. When the top redstone line is depowered, the piston directly powered by the redstone line is uncut. This will schedule a block event for this piston only. When the block event for this piston is executed, it will update the budded piston next to it, scheduling a block event, while at the same time uncutting the redstone wire, which will schedule a block event for the piston on the output. After both of these block events are scheduled, they will both execute. The piston on the output will start extending and the piston in the middle will retract which will update the piston holding the redstone block. After both of these block events execute only then will the block event associated with the redstone block piston will execute. This will cause such piston to retract, removing the power from the redstone line and scheduling another block event to the outdated piston. This block event will occur when the piston is still extending so the piston will instantly finish extending and start retracting.
0-tick generators that involve pistons are widely used because it is easy to control when the 0-tick pulses made by them happen and how long they are.
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 intuitive 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 receives a 1 tick pulse, the block in front of its face will finish its extension after one tick, instead of the usual 3 ticks. What this means in relation to 0 tick pulses is, that if a sticky piston receives a 0 tick pulses, the block in front of its face will finish its extension in 0 ticks, meaning it gets instantly teleported. However, this only applies to sticky pistons. If a normal piston receives a 0 tick pulse, the block in front of its face will need 3 ticks to travel to the next block.