Talk:Tick

Article Mob spawner declares that the tick concerning spawning mechanics is 1/20 seconds, whereas this article uses the term tick for a 1/10 second period. I think something should be changed, anyone has any ideas on the subject? | TheKax | Talk 15:45, 7 August 2011 (UTC)

A 5-clock ticks on once per second, so 5 ticks on and 5 off, totaling at 10 ticks in a second. Unless there's a new definition of a tick, I'd say to change Mob Spawner. Purtip31 23:54, 8 August 2011 (UTC)

Well actually... there is the game definition of a tick. That definition is used by both redstone and mob spawning and almost any other in-game check. A true tick takes 1/20^th of a second, and each "redstone tick" is in-fact two true game ticks. This is unfortunately very confusing and I should probably go and edit the page. *sulks off, muttering*. Also, because the tick governs more than just redstone, though it is most noticeable in that application, it should not be merged with redstone circuits just yet. 👁 BlockSprite tall-grass.png: Sprite image for tall-grass in Minecraft
| Akyute | 02:38, 13 September 2011 (UTC)

👁 Image
 Do Not Merge - If the information on Redstone Ticks is merged then it will cause great confusion on the difference between game ticks and redstone ticks. Leave it be, it isn't broken, don't fix it. 108.171.121.30 01:55, 15 August 2012 (UTC)

Merge - Redundant article is redundant. Ajax2422 04:53, 4 December 2011 (UTC)

👁 Image
 Do Not Merge - Ticks don't necessarily have anything to do with Redstone, and renders them a completely different subject, that subject being the physical game engine. Jononon 6:09, 2 March 2012 (PST) –Preceding unsigned comment was added by 98.149.171.98 ^(Talk) 02:10, 3 March 2012‎ (UTC). Please sign your posts with ~~~~

👁 Image
 Merge - Merge the small part pertaining to redstone with the redstone article: Ticks can be used to measure time. –Preceding unsigned comment was added by 50.104.194.86 ^(Talk) 01:19, 8 March 2012. Please sign your posts with ~~~~

👁 Image
 Merge but don't merge - I agree with the above statement the first half of the article talks about tick as in the game's loop. But, the second half of the article (Methods to produce multiple or single ticks) talks about redstone circuits, that part should be merged. –Preceding unsigned comment was added by 66.207.116.1 ^(Talk) 00:16, 15 March 2012‎ (UTC). Please sign your posts with ~~~~

👁 Image
 Merge but don't merge - As the person above me stated, the second half of the article doesn't have to do with anything except redstone circuits, really. So don't merge the whole page, just the part about redstone ticks. –Preceding unsigned comment was added by NightstormKitty ^{(Talk|Contribs)} 00:30, 18 April 2012‎ (UTC). Please sign your posts with ~~~~

👁 Image
 Merge but don't merge - I agree with the two above me; some of it is redundant but some is not. –Preceding unsigned comment was added by Colabcalub ^{(Talk|Contribs)} 21:23, 29 May 2012‎ (UTC). Please sign your posts with ~~~~

👁 Image
 Not useful - Merging is unnecessary. Just keep the topic together so people can view all types of ticks. - Asterick6 (talk) 06:21, 6 June 2012 (UTC)

👁 Image
 Merge but don't merge - The section explaining what redstone ticks are should stay, but the section on designing circuits for short pulses should go. A link can be added to the pulse limiter section of the redstone circuits page. --Sostratus 00:16, 13 July 2012 (UTC)

👁 Image
 Merge but don't merge I agree with the prior comments to this effect: keep the definition of redstone ticks (though the info should also be on the redstone page), but the pulse circuits should be moved there, it doesn't belong here. --Mental Mouse 18:15, 24 December 2012 (UTC)

In fact, since we have concurring opinions going back to August, I went ahead and did it. --Mental Mouse 21:55, 24 December 2012 (UTC)

can be found here: [1] –Preceding unsigned comment was added by Last username ^{(Talk|Contribs)} 11:55, 11 April 2012‎ (UTC). Please sign your posts with ~~~~

As mentioned in the link above, on every tick, 48 blocks per chunk are chosen for updates. The chance of any particular block being updated is 48/(16 * 16 * 256) = 48/65536, so the chance of it not updating is 65488/65536. After 47 seconds (940 ticks), the chance that a block still hasn't been updated is (65488/65536)940 = 50.22%. This is why the median time between block updates is approximately 47 seconds: half of the blocks will have received updates by then. -- Orthotope 01:30, 27 June 2012 (UTC)

To be more precise, 3 blocks per 16x16x16 mini-chunk are chosen every game tick. The chance of a particular block being chosen in a tick is technically not 3/(16*16*16) = 3/4096, but actually 1 - (4095/4096)^3 = 2.9992676/4096. The blocks picked are independent, and the same block can be chosen multiple times. Mini-chunks without any blocks that respond to block ticks are skipped to spare computation. The average time for a tick on a particular block (not the median) is 68.2666... seconds. Supposedly the random number generating technique used is somewhat poor, but analyzing it for any biases is beyond me. The code for this can be found in the tickBlocksAndAmbience() method of the World.java class. http://mcp.ocean-labs.de/files/jd124/client/net/minecraft/src/World.html#tickBlocksAndAmbiance%28%29 --Sostratus 00:02, 13 July 2012 (UTC)

A linear congruential generator is used to pick the blocks for updates. As Wikipedia explains, an LCG is often a poor choice for generating coordinates, as they tend to lie on a series of distinct planes. However, that only applies when sequentially generated values are used for the coordinates. Instead, Minecraft extracts 4-bit fields from a single generated value, and uses those for the x/y/z coordinates. I ran some simulations, and this appears to solve the problem of serial correlation: all blocks within a section received nearly-equal numbers of ticks (variation of only 0.04%). -- Orthotope 09:47, 7 May 2013 (UTC)

totally disagree because: does ticks have to do with redstone? no. redstone is nothing like ticks.

---

I am not a minecraft player, so I may be wrong.(for those mispellers, rong.)

82.153.116.180 19:06, 12 November 2012 (UTC)

Is the block update radius discussed here the same as the chunk loading radius discussed at Chunk? If not, how do non-loaded chunks get updates? If it is, the text should be changed, because it's not a 15×15 chunk area, it's a radius set in the server properties. --Mental Mouse 22:31, 24 December 2012 (UTC)

The same question came up to me when I red these two pages (Chunk and Tick ... anyone got an answer? (I'm translating this page for the French wiki and I would like to be as precise as possible) --80.118.33.228 15:10, 6 May 2013 (UTC)

As far as I can tell, a 21×21 square of chunks is always loaded around the player, and block ticks are applied in a 15×15 square. Render distance affects how many chunks are visible to the user, and servers can be set to send data about fewer chunks to reduce bandwith usage, but neither of these change how many chunks are loaded or updated. -- Orthotope 09:47, 7 May 2013 (UTC)

Thanks ! French translation done ! --80.118.33.228 15:23, 7 May 2013 (UTC)

In older minecraft, the vision range of the client or single player did not affect where block ticks happened. You could have far vision (16 chunks), and things would only happen around you (15 chunks on a side).

In 1.7.10, and I'd like someone else to verify this before editing the page, in single player, the "render distance" lies. If I say a render distance of 10 chunks, then in reality anything from 8 to 10 chunks will display on my screen, but all 10 chunks of distance are loaded and updated even if it is not displayed. But if I say render distance of 16, then 14 to 16 chunks will display, and 16 chunks of distance will update. Equally, on a server, everything within the server view distance will update

This is a significant change. I don't know if this is a vanilla change, or a forge change (I play modded). Can someone test if this happens in vanilla? Can someone verify that this affects modded as well?

At a minimum, scheduled ticks will happen even outside of this range -- Opis reports, and I've verified this happens -- that a scheduled update will be dispatched to any chunk it got scheduled for, even if that chunk is far enough away that it should unload, even if that chunk was unloaded and had to be loaded to deal with the scheduled tick. This was happening with a forge fluid, not tested with any vanilla block. –Preceding unsigned comment was added by Keybounce (talk • contribs) at 8:47, 21 April 2015 (UTC). Please sign your posts with ~~~~

In my experience, I have noticed render distance in single player and the server render distance directly affects how many chunks are processed, including in 1.8. For example, playing at a low render distance will reduce the mob cap. I recall reading somewhere that behavior was classified as a bug, but since it has consistently existed for a long time, it might be worth noting as current behavior.

As for the displaying chunks, I assume that is because of the fog to create smooth edges cuts off the last two chunks or so. You will notice no fog is added if you play at a render distance higher than your server's render distance –KnightMiner ^t/_c 13:43, 21 April 2015 (UTC).

Does anyone know how ticks are applied to mobs and their status effects? In modded play, I've recently come across some evidence that at when a player departs, at least one status effect (Regeneration) stops being active somewhat before surrounding blocks get unloaded; there's also the matter of mobs stopping motion according to their distance from the player. --MentalMouse42 (talk) 11:14, 23 September 2016 (UTC)

Unfortunately the story is missing here... 12:04, 27 April 2018 (UTC)

Was messing with /gamerule randomTickSpeed and set it to 100000000 or something and nothing is happening...

What's the fix? --23.243.86.149 23:15, 17 December 2020 (UTC)

Set it back to 3.  Nixinova   T   C   23:16, 17 December 2020 (UTC)

I can't... nothing is happening when I do that! -- 23.243.86.149 23:37, 17 December 2020 (UTC)

Use /gamerule randomTickSpeed 3 per Nixinova. The Great Spring (talk | contribs) (Tagalog translation) 23:55, 17 December 2020 (UTC)

"In Java Edition, because random block ticks are granted randomly, there is no way to predict when a block can receive its next tick. The median time between ticks is 47.30 seconds (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 equal or longer than 47.30. However, sometimes it is much longer or shorter: for example, there is a 1.5% chance for the interval to be less than one second and a 1% chance for the interval to be over five minutes. On average, blocks are updated every 68.27 seconds (1365.33 game ticks). For the math behind these numbers, see the Wikipedia entries for the geometric distribution."

So in Java Edition, the default random tick speed rate is 3, meaning blocks are updated every 68.27 seconds --- so does that mean the random tick speed interval is 204.81 / random tick speed rate? 76.64.52.246 21:59, 14 July 2021 (UTC)

What about on bedrock? 2600:387:4:803:0:0:0:66 01:15, 25 August 2024 (UTC)

Probably the same. But please avoid replying to topics more than a year old. -~- Nerdyguy2000   talk   edits 14:05, 25 August 2024 (UTC)

When are functions scheduled for a particular tick actually run within that tick (when using /schedule)? In particular, I'm interested in whether they run before or after the tick and load tags. I assume after, but I can't figure out a way to verify that. – ZacNVR (talk) 15:51, 23 January 2024 (UTC)

Nevermind, it's already in the article. Run as part of the per-dimension ticks, which I guess makes sense (i.e. after tick and load, for anyone wondering). – ZacNVR (talk) 15:56, 23 January 2024 (UTC)

I am wondering where this information on this "Immediate Update Theorem" comes from. As a veteran technical player, I know about and have used these microtick/subtick, block-event delay, and scheduled tick phenomena many times, but have not seen this formal name before. I ask where this comes from, because---if it's from the wiki---I would propose a change to the title. It should be referred to as the "Immediate Update Law" since it describes what happens and not "why?" or "how?" something happens. The "why" would lie in the game code, and this says nothing about the code itself. Similarly, I have never heard of it referred to as a piston tick before, I have only seen mt for microticks, and subticks to refer to any operations in general that occur in the duration of a single tick. I assume that a piston tick or pt is just a microtick but for pistons in particular, so if I were to rewrite this page I would simply add further descriptions of these ticks rather than removing piston ticks, as I am not deluded enough to assume that my experience is absolute.

However, I actually believe that this section should be moved to the redstone page. Subticks are not true ticks, and are simply events that occur in a deterministic order within a single tick. This goes hand-in-hand with the proposed merge of redstone ticks with the redstone page, this would likely be better-suited for that article where things such as extended-2-gt pulses and other block event--related phenomena could be detailed. I do not feel that it makes sense here, but putting a brief overview and redirect link or just a "see also" page might be a good idea.

The page on ice claims that it is subject to chunk ticks, making the freezing rate dependent on the randomTickSpeed gamerule. This is an error on the ice page that should be fixed there (I will probably do that soon) and is beyond the scope of this talk page, but the error here is that chunk ticks are not differentiated properly with random ticks. Ice growth (and cauldron filling) is dependent on random ticks, but it is not labeled under random ticks. Only ice melting is. The reason I have not just changed this is that I am not sure what the wiki is trying to get at. It appears that there is some discussion of things happening in both versions, so there might be a reason why it is not labeled under the rest of the random tick operations. If someone could let me know whether or not this separation was intentional, I would be happy to help remove the ambiguity as it applies. I have a feeling that this is an artifact of an older version as testing in 1.17.1 shows that these operations are not dependent on randomTickSpeed, but I am not sure when this changed or if my 1.17.1 testing environment was altered by fabric (I did use a fully vanilla client for 1.21 testing though).

I hope that my reasoning for asking for clarification before editing is clear, and that this is the correct place to do such a thing. Thank you! Chezrlz009 (talk) 20:45, 4 July 2024 (UTC)

For your first question, the link was deleted by MarkusRost (2462516）, and it linked to https://redstone.fandom.com/zh/wiki/即时更新理论 .This theory is proposed by Sancarn and Selulance in https://youtube.com/watch?v=FCysy1Y1A5g and https://youtube.com/watch?v=ARd2bqvb1N4 on Youtube.

In these videos, they called it "The Immediate Update Bug or The Lever Bug", and they said "this theory" in the end of the 2nd video. They proposed a time unit called "Game tick", but compared with the code, it clearly not the game tick. A few months after these video were seen by Chinese players, the players searched the code, realized that this unit is divided by the end of block event, so players named it "Piston tick", and considered that the theory an important part of Delay Theory(ies). This theory describes "'how' something happens", and help players analyze circuits and explain how short pulses work on piston. But the Delay Theory didn't spread widely, maybe because it's too hard for new players.

For your second advice, there is only a brief description of the piston tick in this page, so I think this section needn't to be moved. Liaoxiangbin (talk) 15:39, 7 July 2024 (UTC)

i would like to use the automatic tick calculator in my own project off this device, is there a place i can find the source code? 166.181.249.225 19:50, 21 January 2025 (UTC)

Here https://github.com/mc-wiki/mcw-calc. Frisk (talk) 19:53, 21 January 2025 (UTC)

It's correct, as crop growth is mentioned under a subsection of the Chunk tick section, where it's stated that a player needs to be within 8 chunks. --MinecraftExp123^{(talk|contribs)} 23:05, 1 October 2025 (UTC)

This is actually not true, at least in Java Edition; this was changed in a 1.21.5 snapshot so that all entity-ticking chunks receive random ticks instead of just those near enough to a player. 👁 align=top
Sightnado ( talk / contribs ) 02:27, 2 October 2025 (UTC)

Random tick applies to any fully loaded chunk starting JE 25w06a, if the 'elsewhere online' you read was published before that, there would only be old info. BTW, can you provide a list of pages which still say the old 8-chunk range of random ticks on this wiki? Hxy123abc (talk) 14:23, 5 October 2025 (UTC)

Resolving as the user who made the feedback did not respond to the latest question in a timely manner. BDJP ^(t|c) 21:24, 28 January 2026 (UTC)

Retrieved from "https://minecraft.wiki/w/Talk:Tick?oldid=3607973"