03 Scheduled Ticks and Scheduled Tick Components
This section explains how Scheduled Ticks and Scheduled Tick Components work.
Basic Section
- Concept and content of Scheduled Ticks
- Common Scheduled Tick Components
- Simple examples
Advanced Section
- Maintenance of Scheduled Tick queues
- Timing analysis of 4gt Observer high-frequency circuits
- In-depth analysis of Comparator Scheduled Tick execution logic
- Scheduled Tick suppression
1 Concept and Content of Scheduled Ticks
1.1 What is a Scheduled Tick?
In Minecraft, many redstone components don't change immediately after being triggered, such as repeaters and comparators. These components always change state after a delay.
Here's a real-world analogy. In the morning, you receive an email, so you plan to handle it in the afternoon and set an alarm. When afternoon comes, the alarm rings, you remember you need to handle the email, so you open your inbox and start processing it.
Note: This "alarm" carries no notes or labels. It only reminds you on your phone, at the correct time, that "something needs doing". As for what specifically needs to be done, the alarm doesn't care. This alarm contains only these elements:
- When to ring
- Which alarm number this is
- How important it is
- On whose phone it rings
- Who to remind
A Scheduled Tick works like this alarm. When a redstone component is triggered, it adds a Scheduled Tick for itself. When the Scheduled Tick executes, it's like the alarm ringing, and the redstone component changes state.
Redstone components whose behavior is controlled by Scheduled Ticks are called Scheduled Tick Components.
1.2 Content of Scheduled Ticks
Like the alarm above, a Scheduled Tick contains only these elements, which we call the information structure of a Scheduled Tick:
- Execution time
triggerTick: when to execute, or how long to delay before execution
Position and block type are straightforward attributes. A block's own Scheduled Tick cannot be executed by other blocks (unless you happen to push it away or break and replace it with another block before it executes its Scheduled Tick), nor can it execute somewhere else in the world.
Execution time refers to when the Scheduled Tick executes at the macro timing level, i.e., which gt the Scheduled Tick should run in. For example, when a repeater set to 1 tick is triggered, it adds a Scheduled Tick for 2gt later, and after 2gt, that Scheduled Tick will execute. What we commonly call "the delay of a Scheduled Tick component" refers to how many gt later the Scheduled Tick executes.
Sub-order refers to the order in which Scheduled Ticks are added at the same time. For example, within the same gt, repeater A is triggered first and repeater B is triggered later. Then, in the sub-order, repeater A comes before repeater B.
Priority is an integer from -3 to 32, where smaller values mean higher priority. That is, within the same gt, a Scheduled Tick with priority -3 always executes before those with priority -2, -1, or 0.
When discussing priority, "higher priority" and "lower priority value" mean the same thing. To avoid ambiguity caused by the concept of "priority" and "priority value", we recommend readers use "a certain component's Scheduled Tick is more prioritized" when explaining to others.
Similarly, just like the alarm above: A Scheduled Tick is just an "alarm reminding the block that something needs to be done". It doesn't care what the block actually does. All behavior when executing a Scheduled Tick is controlled by the block itself; "the behavior of executing a Scheduled Tick" is not part of "the information structure of a Scheduled Tick".
When we say "a certain component already has a Scheduled Tick", we mean that at the current position, there exists an unexecuted Scheduled Tick with the same block type as the current block.3
1.3 Execution Order of Scheduled Ticks
In the previous two articles, we learned about macro timing analysis and became familiar with micro timing. We know that macro timing always takes precedence over micro timing, and the same applies to Scheduled Ticks. For Scheduled Ticks with different execution times, those with earlier execution times always execute first. For Scheduled Ticks with the same execution time, those with higher priority always execute first. For Scheduled Ticks with the same priority, those added earlier (smaller sub-order values) always execute first.
Therefore, when comparing the execution order of Scheduled Ticks, we can follow this logic:
- Compare macro timing: earlier macro timing executes first.
- Compare Scheduled Tick priority: higher priority executes first.
- Compare Scheduled Tick addition order (sub-order): earlier addition executes first.
This is like comparing numbers: macro timing is the hundreds place, priority is the tens place, and addition order is the ones place.
1.4 Example of Scheduled Tick Order
Now, let's look at a practical example.
Given the situation shown in the diagram, the comparator has priority 0 and the repeater has priority -1. Both the comparator and repeater have a delay of 2gt.
- If triggered in different game ticks, you press the comparator's button first, then press the repeater's button. Which note block will sound first?
- If triggered in the same game tick, you press the comparator's button first, then press the repeater's button. Which note block will light up first?
Answers:
- The comparator lights up first. In macro timing, the comparator is triggered first, and then after a certain number of gt, the repeater lights up.
- The repeater lights up first. In terms of Scheduled Ticks, although the comparator adds its Scheduled Tick before the repeater, the repeater's priority is -1, which is more prioritized than the comparator's priority 0. Since Scheduled Tick priority takes precedence over Scheduled Tick addition order, the repeater lights up first.
2 Common Scheduled Tick Components
2.1 Repeater
Repeaters and comparators are collectively called Redstone Diodes or Redstone Gates.4
In Tick and Inter-Tick Timing, we already introduced repeaters and comparators. Now, let's examine the Scheduled Tick behavior of repeaters in more detail.
If a repeater is locked, it will not add a Scheduled Tick, nor will it change state when executing a Scheduled Tick. If a repeater is not locked, it has the following behaviors:
Adding Scheduled Tick behavior:
- When a repeater receives an NC update, it checks its own state. If it does not have a Scheduled Tick and should change state (i.e., it is not lit but has a redstone signal at the input, or it is lit but has no redstone signal at the input), then it adds a Scheduled Tick.
- All Scheduled Ticks added by repeaters have a delay of
repeater delay * 2 gt, except for the following case: - When a repeater is placed, it checks its own state, and if it should change state, it adds a Scheduled Tick for 1gt later.
Executing Scheduled Tick behavior:
- If the repeater is lit, it immediately turns off.
- If the repeater is not lit, it immediately lights up. This step is not affected by the input signal.
- If there is no input signal at this time, it adds another Scheduled Tick (for turning off).
For example:
For instance, if a repeater set to 2 ticks receives a signal with duration <= 4gt5, the repeater's behavior is as follows:
- Receives NC update, adds Scheduled Tick
- After 4gt, executes Scheduled Tick
- Detects that it is not lit, so it immediately lights up
- Detects that there is no redstone signal at the input, adds Scheduled Tick (for turning off)
- After another 4gt, executes Scheduled Tick
- Detects that it is lit, so it immediately turns off
This example covers all Scheduled Tick behaviors of a repeater.
Special priority changes:
- If a repeater points to a horizontally placed redstone diode or points to the input of a redstone diode, the Scheduled Tick's priority is
-3. - Otherwise, if the repeater is in a lit state when adding a Scheduled Tick (i.e., this Scheduled Tick is for turning off), the Scheduled Tick's priority is
-2. - Otherwise, the Scheduled Tick's default priority is
-1.
2.2 Comparator
Adding Scheduled Tick behavior:
- When a comparator receives an NC update, it checks its own state. If it does not have a Scheduled Tick and should change state (i.e., it is not lit but has a redstone signal at the input, or it is lit but has no redstone signal at the input), then it adds a Scheduled Tick.
- All Scheduled Ticks added by comparators have a delay of
2gt, except for: - When a comparator is placed, it checks its own state, and if it should change state, it adds a Scheduled Tick for 1gt later.
Executing Scheduled Tick behavior:
When a comparator executes a Scheduled Tick, it actually only does one thing:
- Update its own output power level based on the comparator's current input state and comparator mode.
The output power level refers to the output power level calculated by the comparator (specific calculation method described later). This update includes two things: updating the power level and sending updates. Moreover, for comparators, the output power level may appear unchanged from the outside, but in reality the comparator still "updates" its own output power level.
Comparators also have slightly more complex update behavior:
Comparator's update sending behavior:
- When executing a Scheduled Tick, if the comparator's powered property changes (i.e., it changes from off to lit, or from lit to off), it first sends an NC update, then sends a PP update.
- If the comparator is in compare mode, or the comparator is in subtract mode and its own output power level changes, it sends an NC update.
For example:
- First, this entire section assumes the comparator actually executed a Scheduled Tick:
- As long as the comparator is in compare mode, even if its output level doesn't change, including changing from 0 to 0, there will be one NC update.
- If the comparator's output power level changes from 0 (off) to 1, 2, 3, 4, 5...14, 15 (lit), or from lit to off, it will first send one NC update, then send one PP update, and finally send another NC update.
- If the comparator is in subtract mode, and its output power level changes from 1, 2, 3, 4, 5... to any other power level, there will only be one NC update.
These behaviors may be useful in some special wiring setups. If readers find this section difficult to understand, they can simply remember the most common uses of comparators: comparing signal sizes and determining whether to output, detecting container capacity, and subtract mode, or refer to the table.
Comparator Output Power Level Calculation
If the signal input is redstone dust or another comparator, the comparator inherits the input power.
If it's a container, refer to Comparator Signal Strength Calculation.
In particular, when there are both container signals and redstone signal inputs, the comparator will prioritize different signal inputs for calculation based on the situation. This phenomenon is also known as container shielding.
Special priority changes:
- If a comparator points to a horizontally placed redstone diode or points to the input of a redstone diode, the Scheduled Tick's priority is
-1 - Otherwise, the Scheduled Tick's default priority is
0
At this point, we can analyze the case from the previous chapter.
2.3 Observer
Adding Scheduled Tick behavior:
- After an observer receives a PP update from the block in front of it, if it is not lit and there is no Scheduled Tick for itself at the current position6, it adds a Scheduled Tick for 2gt later.
Executing Scheduled Tick behavior:
- If it is not lit, it lights up, sends a PP update, then adds a Scheduled Tick for 2gt later, and finally sends an NC update.
- If it is lit, it turns off.
2.4 Redstone Torch
Adding Scheduled Tick behavior
- After a redstone torch receives an NC update, if it is lit but should turn off and there is no Scheduled Tick for itself at the current position, it adds a Scheduled Tick for 2gt later.
Executing Scheduled Tick behavior
- If it is lit but should turn off, it turns off.
- If it burns out, it turns off7, and adds a Scheduled Tick for 160gt later.
- If it is off but should light up, and has not burned out, it lights up.
Should turn off/light up: Whether the block the redstone torch is attached to is a solid block and receives a redstone signal.
Burn out: If a redstone torch lights up 8 times within 60gt, it burns out.
After a redstone torch burns out, you can make it "light up" by breaking and replacing it with a new redstone torch, or wait until 160gt later for the torch to execute its Scheduled Tick and light up on its own.
3 Simple Scheduled Tick Timing Analysis
3.1 Can an Observer Turn Off a Redstone Torch?
Usually not. Let's briefly analyze this:
Both observers and redstone torches have a priority of 0. When an observer lights up, it first sends a PP update, then adds a Scheduled Tick, and finally sends an NC update. Redstone torches receive NC updates. The order of behaviors within Scheduled Tick execution and what updates a component receives fundamentally affect the following analysis. So assuming an observer is facing a solid block that a redstone torch is attached to, its Scheduled Tick order is as follows:
- Observer lights up:
- Sends PP update, nothing happens.
- Observer adds Scheduled Tick
- Sends NC update:
- Redstone torch receives NC update:
- Adds Scheduled Tick
- Redstone torch receives NC update:
2gt later:
- Observer executes Scheduled Tick, turns off.
- Redstone torch executes Scheduled Tick, at this time checks whether it should turn off, finds it should not turn off (because the observer turned off, the attached block is not powered), so it performs no action.
So in summary: the redstone torch finds there's no power when it's about to light up, so it does nothing.
However, at this point we can discover a problem: if I place two observers, one observer used to "trigger" the redstone torch to add a Scheduled Tick, and another used to "continue" the redstone signal to turn off the torch, then can the redstone torch light up? Yes. A simple structure is shown in the figure below:
