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 Edit
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 tiletick priorities are useful EditRepeaters 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) awalys update after repeaters, meaning that one can guarentee 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 repeate is resovled, 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 pistions that would have been powered by quasi-connectivity will react to this 0-tick pulse as the diffrence in tile tick priority will make sure the output reacts before the pistion inside the 0-tick generator..
Chaining repeaters and comparators Edit
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 Edit
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 miniupulate the order in which block events are scheduled to have a power source being removed after the power source in activated in the gametick.
A piston will wait for earlier phaeses of a gametick, such as tileticks, and earlier block events to process before its block event has been processed. When a pistion's block event is been executed, it will turn itself, and if extending or if its a stickiy piston scheduled to retract, the block infront 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 line, or a power source can be removed by turning the block which is powering a redstone source or allowing a connetinon between a power source and the output into block 36.
In this 0-tick pulse generator, the redstone dust will power and the solid block, as well as updating any blocks within the redstone dust upate 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 pistion to be unpowered as well as updating the bottom piston. This will schedule a block event for the bottom pistion to retract at the end of the list. When the bottom pistion's block event executes, it will start retracting, which will remove the power source from the top pistion as well as update the top pistion, which will scheudle a retraction block event at the end of the list. When the top pistion's block event is executed, the pistion immediatly finish 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 of 0-tick pulse generation.
Chaining pistons Edit
Because pistion block events are always added to the end the list, pistoins. The goal of chaining pistions 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 pistion block is executed, but the power source is inconsistand with what the block event it trying to do, the pistion will not respond to it. Although there is no such thing as block event groups, it can be useful to think of pistion 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 1, 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 is 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 souce in a group after which the block events in the output are scheduled will make sure any 0-tick build is non-locatonal.
The 0-tick generator pictured to the right makes use of pistion update chains. When the top redstone line is depowered, the piston directly powered by the redstone line is uncut. This will will schedule a block event for this pistion only. When the block event for this pistion is executed, it will update the budded pistion next to it, scheduling a block event, while at the same time uncutting the redstone wire, which will schedule a block event for the pistion on the output. After both of these block events are schedueld, they will both execute. The piston on the output will start extending and the pistion in the middle will retract which will update the pistion holding the redstone block. After both of these block events execute only then will the block event associated with the redstone block pistion will execute. This will cause such piston to retract, removing the power from the redstone line and scheduling another block event to the outdated pistion. This block event will occur when the pistion is still extending so the pistion will instantly finish extending and start retracting.
0-tick generators that involve pistions are widely used because it is easy to control when the 0-tick puslses made by them happen and how long they are.
Test137e29's weird piston effects (1.8 and earlier) Edit
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: Edit
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: Edit
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: Edit
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 Edit
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 3 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 3 ticks to travel to the next block.