Talk: Tick

Tick inconsistency

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. | Akyute | 02:38, 13 September 2011 (UTC)

Merge With Redstone Circuits

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)

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 ~~~~

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 ~~~~

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 ~~~~

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 ~~~~

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 ~~~~

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)

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)

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)

Explanation of block tick half-time calculation

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)⁹⁴⁰ = 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)

merging redstone ticks with redstone-I disagree.

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)

A new issue regarding chunks

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)

Inconsistency with 1.7.10 and vision range

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).