Minecraft:Tick: Difference between revisions
More actions
Sync: updated from Minecraft |
Sync: updated from Minecraft |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{ | {{about||random ticks|Random Tick|the command|Commands/tick|function uses|Tick.json}} | ||
Nearly all video games (including ''Minecraft'') are driven by one big {{w|Control flow#Loops|program loop}}. Just as every gear in a clock is synchronized with the pendulum, every task involved in advancing a game simulation is synchronized with the game loop. Appropriately, one cycle of the game loop is called a '''tick'''. | Nearly all video games (including ''Minecraft'') are driven by one big {{w|Control flow#Loops|program loop}}. Just as every gear in a clock is synchronized with the pendulum, every task involved in advancing a game simulation is synchronized with the game loop. Appropriately, one cycle of the game loop is called a '''tick'''. | ||
| Line 79: | Line 79: | ||
Most blocks ignore this tick, but some use it to do something: | Most blocks ignore this tick, but some use it to do something: | ||
*[[Minecraft:Crops]] may grow or uproot. | *[[Minecraft:Crops]] may grow or uproot. | ||
*[[Minecraft: | *[[Minecraft:Mushrooms]] may spread or uproot. | ||
* | *{{BlockLink|Vines}} may spread. | ||
*{{ | *{{BlockLink|Fire}} may burn out or spread.{{only|bedrock|short=1}} | ||
* | *{{BlockLink|Ice}} and {{BlockLink|snow}} layers may melt. | ||
* | *{{BlockLink|Leaves}} may decay. | ||
* | *{{BlockLink|Farmland}} hydration is updated. | ||
* | *{{BlockLink|Cactus}}, {{BlockLink|sugar cane}}, {{BlockLink|kelp}}, {{BlockLink|bamboo}}, {{BlockLink|chorus flower}}s, {{BlockLink|mangrove propagule}}s and {{BlockLink|sweet berry bush}}es may grow. | ||
* | *{{BlockLink|Grass block}}s and {{BlockLink|mycelium}} may spread. | ||
*Grass | *{{BlockLink|Grass block}}s, {{BlockLink|mycelium}}, and {{BlockLink|nylium}} may decay (only if the condition is met). | ||
*[[Minecraft:Sapling]]s may grow into a [[Minecraft:tree]]. | *[[Minecraft:Sapling]]s may grow into a [[Minecraft:tree]]. | ||
* | *{{BlockLink|Lava}} may set fires nearby.<ref group=note>{{IN|JE}}, this requires a player within an 8-chunk radius. However, {{cmd|gamerule allowFireTicksAwayFromPlayer}} removes this requirement if set to true.</ref> | ||
* | *{{BlockLink|Mud}} may turn into {{BlockLink|clay}} if placed on top of a block with {{BlockLink|pointed dripstone}} underneath. | ||
*Lit | *Lit {{BlockLink|redstone ore}} turns off. | ||
* | *{{BlockLink|Nether portal}} blocks may spawn a [[Minecraft:zombified piglin]]. | ||
* | *{{BlockLink|Turtle egg}}s crack or hatch. | ||
* | *{{BlockLink|Campfire}} smoke appears. | ||
* | *{{BlockLink|Budding amethyst}} may grow an {{BlockLink|amethyst bud}} on any of its sides as longs as there is no solid block. | ||
* | *{{BlockLink|Block of Copper|text=Copper block}}s (or any of its non-oxidized variants) may advance one stage in [[Minecraft:oxidation]]. | ||
*{{BlockLink|pointed dripstone}} may fill a {{BlockLink|cauldron}} below. | |||
* | *{{BlockLink|pointed dripstone}} may grow a stalagmite/stalactite if the conditions are met. | ||
Because random block ticks are granted randomly, there is no way to predict when a block can receive its next tick. {{IN|java}}, the ''median'' time between ticks is '''47.30''' seconds (<math>\log_{\frac{4096-3}{4096}}(0.5) \approx</math> 946.03 game ticks). That is, there is a 50% chance for the interval to be equal or shorter than 47.30 seconds and a 50% chance for it to be longer than 47.30. However, sometimes it is much longer or shorter: for example, there is a 1.38% chance for the interval to be less than one second and a 1.23% chance for the interval to be over five minutes. On ''average'', blocks are updated every '''68.27''' seconds (<math>\frac{4096}{3} \approx</math> 1365.33 game ticks). For the math behind these numbers, see the Wikipedia entries for the [[Minecraft:wikipedia:geometric distribution|geometric distribution]]. | Because random block ticks are granted randomly, there is no way to predict when a block can receive its next tick. {{IN|java}}, the ''median'' time between ticks is '''47.30''' seconds (<math>\log_{\frac{4096-3}{4096}}(0.5) \approx</math> 946.03 game ticks). That is, there is a 50% chance for the interval to be equal or shorter than 47.30 seconds and a 50% chance for it to be longer than 47.30. However, sometimes it is much longer or shorter: for example, there is a 1.38% chance for the interval to be less than one second and a 1.23% chance for the interval to be over five minutes. On ''average'', blocks are updated every '''68.27''' seconds (<math>\frac{4096}{3} \approx</math> 1365.33 game ticks). For the math behind these numbers, see the Wikipedia entries for the [[Minecraft:wikipedia:geometric distribution|geometric distribution]]. | ||
| Line 114: | Line 114: | ||
== Redstone tick == | == Redstone tick == | ||
{{for|Java Edition's community-made term|Redstone tick (term)}} | |||
{{see also|Redstone mechanics}} | {{see also|Redstone mechanics}} | ||
{{exclusive|bedrock|section=1}} | {{exclusive|bedrock|section=1}} | ||
'''Redstone tick''' is | '''Redstone tick''' is the basic unit of time in redstone mechanics: a delay of two [[Minecraft:game tick]]s, or {{frac|2|20}} {{frac|1|10}} of a second, giving 10 redstone ticks per standard 20-tick second. | ||
The redstone system is calculated independently of the main | The redstone system is calculated independently of the main [[Minecraft:game tick]] loop. Each redstone tick is split into two deterministic phases: a produce tick (P-tick) and a consume tick (C-tick). These two phases make up a single redstone tick | ||
=== Tick cycle === | |||
* Produce tick ({{va|P-tick}}) — occurs first, on odd-numbered game ticks; components output or send their signal. | |||
* | * Consume tick ({{va|C-tick}}) — occurs second, on even-numbered game ticks; components read and respond to the signals they receive. | ||
* | |||
{| class="wikitable" style="text-align:center;" | |||
! Redstone tick !! Game tick !! Time (s) !! Phase | |||
|- | |||
| rowspan="2" | 1 || 1 || 0.05 || P-tick | |||
|- | |||
| 2 || 0.10 || C-tick | |||
|- | |||
| rowspan="2" | 2 || 3 || 0.15 || P-tick | |||
|- | |||
| 4 || 0.20 || C-tick | |||
|- | |||
| rowspan="2" | 3 || 5 || 0.25 || P-tick | |||
|- | |||
| 6 || 0.30 || C-tick | |||
|- | |||
| rowspan="2" | 4 || 7 || 0.35 || P-tick | |||
|- | |||
| 8 || 0.40 || C-tick | |||
|- | |||
| rowspan="2" | 5 || 9 || 0.45 || P-tick | |||
|- | |||
| 10 || 0.50 || C-tick | |||
|- | |||
| rowspan="2" | 6 || 11 || 0.55 || P-tick | |||
|- | |||
| 12 || 0.60 || C-tick | |||
|- | |||
| rowspan="2" | 7 || 13 || 0.65 || P-tick | |||
|- | |||
| 14 || 0.70 || C-tick | |||
|- | |||
| rowspan="2" | 8 || 15 || 0.75 || P-tick | |||
|- | |||
| 16 || 0.80 || C-tick | |||
|- | |||
| rowspan="2" | 9 || 17 || 0.85 || P-tick | |||
|- | |||
| 18 || 0.90 || C-tick | |||
|- | |||
| rowspan="2" | 10 || 19 || 0.95 || P-tick | |||
|- | |||
| 20 || 1.00 || C-tick | |||
|} | |||
=== Component behavior === | |||
== | * [[Minecraft:Power components]]/[[Minecraft:Transmission components]] ([[Minecraft:repeater]]s, [[Minecraft:comparator]]s, [[Minecraft:redstone torch]]s, [[Minecraft:observer]]s, etc.) read their input during a P-tick; after their configured delay, they write their new output on the following C-tick. | ||
* [[Minecraft:Mechanism components]] ([[Minecraft:piston]]s, [[Minecraft:redstone lamp]]s, [[Minecraft:door]]s, etc.) activate during a C-tick and change block state; the resulting block update is processed on the next P-tick. | |||
* [[Minecraft:Redstone dust]] instead of following the 10-tick redstone cycle, it updates its power state on every game tick (20 times per second) which lets it carry 1 game tick long pulses. A dust line powered on an odd tick activates P-tick components, while one powered on an even tick activates C-tick components, meaning redstone dust can be pulsed for 1-tick for phase-specific P- and C-component activations. Its visual state only refreshes on produce ticks, meaning if it is only ticked on a consume tick, it will look off, even though it is technically on. | |||
* [[Minecraft:Armor stand]]s and [[Minecraft:Sulfur Cube]]s that have absorbed TNT activate on both P- and C-ticks, making them the few components that respond on all 20 game ticks rather than 10. Other [[Minecraft:entities]] that interact with redstone, such as [[Minecraft:minecarts with hoppers]], and [[Minecraft:minecarts with TNT]], might also behave the same way.{{needs testing}} | |||
==Java Edition's community-made terms== | |||
{{exclusive|java|section=1}} | {{exclusive|java|section=1}} | ||
=== Redstone tick === | |||
The term "'''redstone tick'''" is a community-made term describing a basic unit of time in redstone mechanics: a delay of two [[Minecraft:game tick]]s, or {{frac|2|20}} {{frac|1|10}} of a second. However, no components are strictly tied to a mandatory alignment of 2-game-tick increments. This term references & exists because most redstone components, such as repeaters, torches, comparators, etc, have delays in increments of 2 game ticks. For example, a redstone repeater can be set to delays of 2, 4, 6, or 8 game ticks, which could instead be described as 1 to 4 redstone ticks. There is no "redstone tick" hard-coded unit in the game's engine. | |||
==== Half–redstone tick ==== | |||
Certain features like scaffolding or leaves propagating updates, or a piston with 1-game-tick start delay, introduce a community-made term "half–redstone ticks," meaning one [[Minecraft:game tick]]. | |||
=== Piston tick === | |||
The '''piston tick''' is a different way to divide the game tick, based on the ''Immediate Update Theory'' by Sancarn and Selulance.<ref>Referred to as "immediate update bug" or "lever bug" in the original video https://www.youtube.com/watch?v=HCgkllZq338</ref> It was created by the Chinese redstone community in order to simplify the calculation of piston timings, but it never gained popularity in the Western community. | The '''piston tick''' is a different way to divide the game tick, based on the ''Immediate Update Theory'' by Sancarn and Selulance.<ref>Referred to as "immediate update bug" or "lever bug" in the original video https://www.youtube.com/watch?v=HCgkllZq338</ref> It was created by the Chinese redstone community in order to simplify the calculation of piston timings, but it never gained popularity in the Western community. | ||
| Line 147: | Line 196: | ||
=== ''Java Edition'' === | === ''Java Edition'' === | ||
{{HistoryTable | {{HistoryTable | ||
|{{HistoryLine|java pre-classic}} | |||
|{{HistoryLine||Cave game tech test|Added game ticks. | |||
|The game runs at a fixed rate of 60 ticks a second, so one tick happens every 0.016̃ seconds (16̃ milliseconds or 1/60th of a second).}} | |||
|{{HistoryLine|???}} | |||
|{{HistoryLine||???|link=none|The game now runs at a fixed rate of 20 ticks a second, so one tick happens every 0.05 seconds (50 milliseconds or 1/20 seconds).}} | |||
|{{HistoryLine|java}} | |{{HistoryLine|java}} | ||
|{{HistoryLine||1.8|dev=14w17a|Added the [[Minecraft:game rule]] {{cd|randomTickSpeed}}.}} | |{{HistoryLine||1.8|dev=14w17a|Added the [[Minecraft:game rule]] {{cd|randomTickSpeed}}.}} | ||
Latest revision as of 11:11, 25 July 2026
|
For the {{{Description}}} of the same name, see [[{{{Destination}}}]]. |
Nearly all video games (including Minecraft) are driven by one big Template:W. Just as every gear in a clock is synchronized with the pendulum, every task involved in advancing a game simulation is synchronized with the game loop. Appropriately, one cycle of the game loop is called a tick.
Game tick
A game tick is where Minecraft's game loop runs once. The game normally runs at a fixed rate of 20 ticks per second, so one tick happens every 0.05 seconds (50 milliseconds or 1/20 seconds), making an in-game day last exactly 24 000 ticks (20 minutes). However, if the computer is unable to keep up with this speed, the amount of game ticks per second (TPS) decreases. As the vast majority of actions are timed based on tick count rather than on real time, this means that many things take longer on a slower computer.
A statistic related to ticks per second (TPS) is milliseconds per tick (MSPT), the time a server actually uses to compute a tick. The TPS can be maintained at 20 only if the MSPT is no higher than 50. The following often contribute to server-side lag:
- Minecraft:Hoppers constantly try to search for items above them. Covering a hopper with any Minecraft:solid block (except Minecraft:bee nests and Minecraft:beehives), stops this check for items; Minecraft:composters can also be used for this purpose and are even better for performance compared to solid blocks. Alternatively, use Minecraft:water flow-based transport which is faster in bulk.
- Minecraft:Redstone components (especially redstone dust), as they can cause excessive amounts of Minecraft:block updates and/or Minecraft:light updates. Disabling redstone contraptions and clocks when not in use can help mitigate this.
- Minecraft:Mob AI. Large amounts of mobs. To mitigate this, torches can be used to prevent hostile Minecraft:mob spawning. As for animal farms-related lag, make sure to use entity-efficient farm designs.
- Random Tick Speed. If the random tick speed is set too high, it can cause the MSPT to rise unusually.
The MSPT value is displayed in the F3 Minecraft:debug screen as "ms ticks" Template:In. The frame time graph (Template:Key) shows the TPS value. Both displays are available only as a multiplayer host or singleplayer since the stats come from the integrated server of your Minecraft game.
Template:IN, tick rates can be controlled by the command Template:Cmd.
Game process
Template:IN, in each game loop the following actions are processed in order:
- Reset next tick time if lagging 2s behind expected tick time
- Compute next tick time
- Increment tick count
- Functions with [[Minecraft:Function_(Java_Edition)#Invocation_from_function_tags|Template:Code or Template:Code tags]] are executed
- Send time every 20 game ticks to players
- Each Minecraft:dimension is ticked in order of Minecraft:Overworld, the Minecraft:Nether, the Minecraft:End, and Minecraft:custom dimensions. For each dimension:
- Update Minecraft:world border bounds
- Advance Minecraft:weather cycle
- Update Minecraft:daylight cycle time
- Player sleeping logic
- Run scheduled commands
- Execute Scheduled block ticks
- Execute Scheduled fluid ticks
- Minecraft:Raid logic
- Update chunks load level
- For all chunks in random order:
- Spawn mobs
- Tick ice and snow
- Random ticks
- Send block changes to players
- Update points of interest
- Unloads chunks
- Execute Minecraft:block events
- Tick dragon fight
- For all non-passenger entities:
- Check if it can despawn
- Tick entity
- Tick passengers
- Tick block entities
- Handle game events
- Send queued packets and handle incoming packets for each player
- Send player info to players
- Autosave every 6000 ticks
- Run pending tasks and wait for next tick
Chunk tick
As a part of a game tick, specific Minecraft:chunks are ticked on every game tick.
Template:IN, chunks with loading type of entity ticking (see Minecraft:Chunk#Level and load type) are ticked on every game tick. This primarily includes chunks in the simulation distance, but chunks loaded through other methods are also random-ticked. Mob spawning and lightning strikes require a player within 8 chunks to occur, even if the chunk is fully loaded. Precipitation-related actions and all other random tick actions (such as crop growth) do not require any player to be near the chunk.
Template:IN, all chunks inside Minecraft:simulation distance (or specified in the /tickingarea command) are ticked on every game tick.
In both editions, the following things happen when a chunk gets ticked:
- Mobs naturally spawn.<ref group=note name=proximity>In Template:JE, this requires a player within an 8-chunk radius.</ref>
- During a Minecraft:thunderstorm, lightning may strike somewhere in the chunk (Template:Frac chance).<ref group=note name=proximity/>
- Template:Frac chance that one column is chosen for weather checks on the topmost block:
- If in a cold biome, Minecraft:water freezes into ice if possible.
- If Minecraft:snowing, a Minecraft:snow layer is placed if possible.
- Additionally, cauldrons can be filled with Minecraft:powder snow.
- If Minecraft:raining, a Minecraft:cauldron is filled with water.
- A certain number of blocks within the chunk receive random block ticks, as described below.
Random tick
Minecraft:Chunks consist of one subchunk per 16 blocks of height, each one being a 16×16×16=4096 block cube. Subchunks are distributed vertically starting at the lowest y level. Every chunk tick, some blocks are chosen at random from each subchunk in the chunk. The blocks at those positions are given a "random tick". Subchunks that do not contain at least one block that can react to random ticks are skipped. All blocks are a possible target of a random tick, including Minecraft:air.
Template:IN, the number of blocks chosen from each subchunk is specified by Template:Cmd (defaults to 3), and one block can be chosen multiple times in one chunk tick. Template:IN, it also depends on Template:Cd (defaults to 1), but it specifies only relative speed instead of the exact number.
Most blocks ignore this tick, but some use it to do something:
- Minecraft:Crops may grow or uproot.
- Minecraft:Mushrooms may spread or uproot.
- Template:BlockLink may spread.
- Template:BlockLink may burn out or spread.Template:Only
- Template:BlockLink and Template:BlockLink layers may melt.
- Template:BlockLink may decay.
- Template:BlockLink hydration is updated.
- Template:BlockLink, Template:BlockLink, Template:BlockLink, Template:BlockLink, Template:BlockLinks, Template:BlockLinks and Template:BlockLinkes may grow.
- Template:BlockLinks and Template:BlockLink may spread.
- Template:BlockLinks, Template:BlockLink, and Template:BlockLink may decay (only if the condition is met).
- Minecraft:Saplings may grow into a Minecraft:tree.
- Template:BlockLink may set fires nearby.<ref group=note>Template:IN, this requires a player within an 8-chunk radius. However, Template:Cmd removes this requirement if set to true.</ref>
- Template:BlockLink may turn into Template:BlockLink if placed on top of a block with Template:BlockLink underneath.
- Lit Template:BlockLink turns off.
- Template:BlockLink blocks may spawn a Minecraft:zombified piglin.
- Template:BlockLinks crack or hatch.
- Template:BlockLink smoke appears.
- Template:BlockLink may grow an Template:BlockLink on any of its sides as longs as there is no solid block.
- Template:BlockLinks (or any of its non-oxidized variants) may advance one stage in Minecraft:oxidation.
- Template:BlockLink may fill a Template:BlockLink below.
- Template:BlockLink may grow a stalagmite/stalactite if the conditions are met.
Because random block ticks are granted randomly, there is no way to predict when a block can receive its next tick. Template:IN, the median time between ticks is 47.30 seconds (<math>\log_{\frac{4096-3}{4096}}(0.5) \approx</math> 946.03 game ticks). That is, there is a 50% chance for the interval to be equal or shorter than 47.30 seconds and a 50% chance for it to be longer than 47.30. However, sometimes it is much longer or shorter: for example, there is a 1.38% chance for the interval to be less than one second and a 1.23% chance for the interval to be over five minutes. On average, blocks are updated every 68.27 seconds (<math>\frac{4096}{3} \approx</math> 1365.33 game ticks). For the math behind these numbers, see the Wikipedia entries for the geometric distribution.
<references group="note"/>
Scheduled tick
Some blocks can request a tick sometime in the future. These "scheduled ticks" are used for things that have to happen in a predictable pattern—for instance, Minecraft:redstone repeaters schedule a tick to change state Template:In, Minecraft:water schedules a tick when it needs to flow.
During the scheduled tick phase, each block position that had previously requested a scheduled tick for this game tick gets ticked.
Template:IN, there are two types of scheduled ticks: block ticks and fluid ticks. Block ticks are executed first based on priority, and then based on scheduling order. A lower value for priority results in earlier execution during the scheduled tick phase. If a Minecraft:redstone repeater is facing the back or side of another diode, its block tick has a priority of -3. If a redstone repeater is depowering, it has a priority of -2. Otherwise, the repeater has a priority of -1. If a Minecraft:redstone comparator is facing the back or side of another diode, it has a priority of -1. All other block ticks have a priority of 0. Then, each block with a scheduled fluid tick get a tick. Fluid ticks do not use priorities and are ordered based on scheduling order.
Template:IN, the maximum number of scheduled ticks per game tick is 65,536. Template:IN, the maximum number of scheduled ticks in a chunk per game tick is 100.
Redstone tick
Template:For Template:See also Template:Exclusive Redstone tick is the basic unit of time in redstone mechanics: a delay of two Minecraft:game ticks, or Template:Frac Template:Frac of a second, giving 10 redstone ticks per standard 20-tick second.
The redstone system is calculated independently of the main Minecraft:game tick loop. Each redstone tick is split into two deterministic phases: a produce tick (P-tick) and a consume tick (C-tick). These two phases make up a single redstone tick
Tick cycle
- Produce tick (Template:Va) — occurs first, on odd-numbered game ticks; components output or send their signal.
- Consume tick (Template:Va) — occurs second, on even-numbered game ticks; components read and respond to the signals they receive.
| Redstone tick | Game tick | Time (s) | Phase |
|---|---|---|---|
| 1 | 1 | 0.05 | P-tick |
| 2 | 0.10 | C-tick | |
| 2 | 3 | 0.15 | P-tick |
| 4 | 0.20 | C-tick | |
| 3 | 5 | 0.25 | P-tick |
| 6 | 0.30 | C-tick | |
| 4 | 7 | 0.35 | P-tick |
| 8 | 0.40 | C-tick | |
| 5 | 9 | 0.45 | P-tick |
| 10 | 0.50 | C-tick | |
| 6 | 11 | 0.55 | P-tick |
| 12 | 0.60 | C-tick | |
| 7 | 13 | 0.65 | P-tick |
| 14 | 0.70 | C-tick | |
| 8 | 15 | 0.75 | P-tick |
| 16 | 0.80 | C-tick | |
| 9 | 17 | 0.85 | P-tick |
| 18 | 0.90 | C-tick | |
| 10 | 19 | 0.95 | P-tick |
| 20 | 1.00 | C-tick |
Component behavior
- Minecraft:Power components/Minecraft:Transmission components (Minecraft:repeaters, Minecraft:comparators, Minecraft:redstone torchs, Minecraft:observers, etc.) read their input during a P-tick; after their configured delay, they write their new output on the following C-tick.
- Minecraft:Mechanism components (Minecraft:pistons, Minecraft:redstone lamps, Minecraft:doors, etc.) activate during a C-tick and change block state; the resulting block update is processed on the next P-tick.
- Minecraft:Redstone dust instead of following the 10-tick redstone cycle, it updates its power state on every game tick (20 times per second) which lets it carry 1 game tick long pulses. A dust line powered on an odd tick activates P-tick components, while one powered on an even tick activates C-tick components, meaning redstone dust can be pulsed for 1-tick for phase-specific P- and C-component activations. Its visual state only refreshes on produce ticks, meaning if it is only ticked on a consume tick, it will look off, even though it is technically on.
- Minecraft:Armor stands and Minecraft:Sulfur Cubes that have absorbed TNT activate on both P- and C-ticks, making them the few components that respond on all 20 game ticks rather than 10. Other Minecraft:entities that interact with redstone, such as Minecraft:minecarts with hoppers, and Minecraft:minecarts with TNT, might also behave the same way.Template:Needs testing
Java Edition's community-made terms
Redstone tick
The term "redstone tick" is a community-made term describing a basic unit of time in redstone mechanics: a delay of two Minecraft:game ticks, or Template:Frac Template:Frac of a second. However, no components are strictly tied to a mandatory alignment of 2-game-tick increments. This term references & exists because most redstone components, such as repeaters, torches, comparators, etc, have delays in increments of 2 game ticks. For example, a redstone repeater can be set to delays of 2, 4, 6, or 8 game ticks, which could instead be described as 1 to 4 redstone ticks. There is no "redstone tick" hard-coded unit in the game's engine.
Half–redstone tick
Certain features like scaffolding or leaves propagating updates, or a piston with 1-game-tick start delay, introduce a community-made term "half–redstone ticks," meaning one Minecraft:game tick.
Piston tick
The piston tick is a different way to divide the game tick, based on the Immediate Update Theory by Sancarn and Selulance.<ref>Referred to as "immediate update bug" or "lever bug" in the original video https://www.youtube.com/watch?v=HCgkllZq338</ref> It was created by the Chinese redstone community in order to simplify the calculation of piston timings, but it never gained popularity in the Western community.
The piston tick starts in the entity phase of the game tick and ends in the block event phase, therefore a piston always takes 3 piston ticks to extend or retract, without any start delay. Redstone components that use scheduled ticks lose 1 piston tick of delay depending on how they are powered (for example this happens when a repeater gets powered by a redstone block that was pushed by a piston).
History
Java Edition
Bedrock Edition
References
Template:Navbox Java Edition technical Template:Navbox Bedrock Edition
Minecraft:de:Tick Minecraft:es:Tic Minecraft:fr:Tick Minecraft:it:Tick Minecraft:ja:ティック Minecraft:ko:틱 Minecraft:lzh:刻 Minecraft:pl:Tick Minecraft:pt:Tique Minecraft:ru:Такт Minecraft:uk:Такт Minecraft:zh:刻