02 A First Look at Intra-Tick Timing
1 Observing Intra-Tick Timing
One day, Little B built a contraption:
Can you guess what will happen when the button is pressed?
- Nothing will happen
- The left piston will extend
- The right piston will extend
- Both pistons will extend simultaneously
- The game will crash
So Little B pressed the button
The... the left piston extended!!!!!!
Based on what they learned from 01-Ticks and Inter-Tick Timing a few days ago, they worked through the following calculation:
This repeater has a 2gt delay, that comparator has a 2gt delay...? Wow, both pistons should extend simultaneously! So why did only one piston extend? They're clearly in the same gt but there's a sequence, isn't gt the smallest unit anymore?
Faced with this question, the extremely clever Little B came to an astonishing conclusion:
The game has a bug!
Of course not! Every player should understand this: in Minecraft, most game logic runs on a single thread. That means, from a logical standpoint, events always execute in some order, never truly at the same time!
So it all adds up. Within a single 1gt, there must be some finer timing at work. We call this fine-grained timing within one tick intra-tick timing. As shown above, running a test like this—where things theoretically happen in the same gt yet still have a sequence—is how you observe intra-tick timing.
Here's another example:
When the button is pressed, the two contraptions show the following behavior:
Both are clearly in the same gt, yet adding a single repeater changes everything. What's going on? This article takes a closer look at these phenomena.
You might be wondering: what's the practical use?
All sorts of things! Whether you're building extremely complex redstone contraptions or doing basic precise timing analysis, intra-tick timing comes into play. Research into intra-tick timing theory has also pushed redstone research forward in major ways, enabling upper limit detection, BED, and other advanced redstone contraptions and theories.
Here's a passage from Mr. Void:
...
Learning intra-tick timing is necessary not just to solve design problems or explain previously mysterious observations. More importantly, many people underestimate intra-tick timing and refuse to study it, seeing it only as a source of headaches. They run into intra-tick timing issues in redstone design all the time, yet they don't realize that intra-tick timing is one of the most powerful tools available. Using it well can greatly simplify redstone circuit design and improve machine performance. Without this knowledge, many people never even realize the tool exists. For the sake of healthy community growth, this situation should be addressed.
2 Micro-Timing Theory
2.1 Phase Division of Micro-Timing
Think of 1gt like one day in the real world. Within a day, things happen in a set order: waking up, breakfast, lunch, dinner, sleeping... In Minecraft, timing measured in whole 1gt units is called macro timing, while the finer subdivisions within a single 1gt are called micro-timing.
As we established earlier, MC always executes things in a fixed priority order. Through source code analysis, experiments, and other methods, we've found that Minecraft roughly follows this sequence within each 1gt:
- World Tick Update, abbreviated as WTU. The game maintains a "timer" bound to the world. When the world is created, this "timer" starts at 0. During this phase, the "timer" increments by 1. The nth tick is the World Tick Update phase that brings the "timer" to n.
- Schedule Tick / Tile Tick / Next Tick Entry*, abbreviated as TT/NTE*. Most components with delayed execution behavior are controlled by "Scheduled Tick" and executed during the Scheduled Tick phase. (The mention of NTE and the incorrect translation of Next Tick Entry is included to help readers understand some early documents; we don't recommend continuing to use these two names.)
- Chunk Tick, abbreviated as CT. Chunk Tick covers lightning, snow, and Random Tick. During this phase, the game first handles lightning, snow, and similar events, then processes Random Tick: when a player is nearby, "crop growth", "grass block spread", "water freezing", and other random tick events may occur. In each Chunk Tick phase, the game iterates through all chunks near the player, then randomly selects blocks within those chunks to trigger these events.
- Block Event, abbreviated as BE. Things like piston pushing/pulling and note blocks playing sounds happen in this phase. Take pistons as an example: when a piston detects that its [actual state] doesn't match its [powered state], it adds a "Block Event". "Block Events" added during the Block Event phase execute in that same phase, while "Block Events" added during other phases are queued for the next Block Event phase. Continuing the piston example, during this phase the piston places moving blocks (b36) at the target positions of blocks it's about to push or pull.
- Entity Update, abbreviated as EU. Every tick, entities handle movement, AI, and other behaviors. All entity behaviors, such as "creature movement", "TNT explosions", and "monster attacks", occur in this phase. Non-player "activation" of pressure plates and tripwires, which produces redstone signals, also happens in this phase.
- Block Entity / Tile Entity, abbreviated as TE. Some blocks need to run their own logic every tick, and this happens in the Block Entity phase. During the Block Entity phase, hoppers "absorb" and "transfer" items. Blocks pushed by pistons become moving blocks (b36), which execute "push entity" logic during the first two Block Entity phases after creation, then revert to normal blocks on the third Block Entity phase.
- Async Task / Network Update, abbreviated as AT/NU, also called Player Action. "Player actions" are actually network packets sent from the client to the server. During this phase, at the end of each tick, the server will uniformly execute all "player action" packets received during this tick.
These are the main game phases you'll encounter in typical analysis. The rest of this article builds on these events.
2.2 Instant
As we've seen, 1gt is divided into different phases. Just as breakfast is for morning and lunch is for noon, many events in Minecraft can only happen in specific phases and follow a set order. But some events respond "immediately", the way you can grab a drink whenever you're thirsty, regardless of the time of day.
If a block's behavior can occur in any phase and is triggered only by block updates, it's called an instant component.
For example, redstone dust turning on or off is instant. If a player flips a lever, the redstone dust can turn off during the player action phase; if a piston pushes away a redstone block, the dust can turn off during the block event phase.
2.3 Delayed
If there are instant events, there must also be "delayed" ones. For example, if a player places a redstone block that activates a repeater, the repeater will light up 2gt later. This lighting has a delay, is controlled by the game (via scheduled ticks), and occurs in a specific phase (the Scheduled Tick phase), so it's not an instant event.
In the following sections, we'll go into detail about each of these game phases.
2.4 Common Components and Their Operating Phases
2.5 Basic Analysis of Intra-Tick Timing
Let's walk through a basic example.
In the figure below, every command block runs the command time query gametime
Rising edge (Pull down lever, sticky piston extends):
Falling edge (Pull back lever, sticky piston retracts):
(Adapted from an example by void)
Footnotes
-
However, pressure plates can only be activated by entity movement, so in practice they only trigger during Entity Update or Player Action. Similarly, buttons can only be pressed by players or arrows, so they're also limited to these two phases. ↩
-
b36: minecraft:moving_piston, moving piston. ↩
-
When a sticky piston retracts and there's b36 in front of it, the b36 is immediately placed in its final position. This is what's known as a sticky piston short pulse. ↩