<!-- 
RSS generated by JIRA (9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13) at Sun Jan 12 11:51:58 UTC 2025

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Mojang Studios Jira</title>
    <link>https://bugs.mojang.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en</language>    <build-info>
        <version>9.12.2</version>
        <build-number>9120002</build-number>
        <build-date>10-01-2024</build-date>
    </build-info>


<item>
            <title>[MC-711] Tile ticks of connected redstone components might be executed in the wrong order when unloading/reloading chunks</title>
                <link>https://bugs.mojang.com/browse/MC-711</link>
                <project id="10400" key="MC">Minecraft: Java Edition</project>
                    <description>&lt;h3&gt;&lt;a name=&quot;Thebug&quot;&gt;&lt;/a&gt;The bug&lt;/h3&gt;
&lt;p&gt;Sometimes repeater clocks may freeze due to the way tile ticks are saved and updated. Most cases of that already got fixed and it already got a lot better compared to when the issue was created. This happens when the repeaters are in different chunks.&lt;/p&gt;

&lt;h3&gt;&lt;a name=&quot;Howtoreproduce&quot;&gt;&lt;/a&gt;How to reproduce&lt;/h3&gt;
&lt;ol&gt;
	&lt;li&gt;Move to a location outside of the spawn chunks. The spawn chunks are close to the location you are when you type &lt;tt&gt;/kill&lt;/tt&gt; without having a bed spawn. Move far away from there.&lt;/li&gt;
	&lt;li&gt;Hit &lt;tt&gt;F3&lt;/tt&gt; + &lt;tt&gt;G&lt;/tt&gt; to show chunk borders.&lt;/li&gt;
	&lt;li&gt;Build a repeater clock in such a way that the repeaters are located in two different chunks.&lt;/li&gt;
	&lt;li&gt;Now move away from the clock in such a way that the chunk of one repeater is closer than the other. Move away until you can&apos;t see either of the repeaters anymore and maybe a little further to be extra sure. You can lower your render distance if you want to make this happening faster.&lt;/li&gt;
	&lt;li&gt;Now move closer to your clock again. The clock is likely to be stuck now.&lt;br/&gt;
&lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;a id=&quot;148352_thumb&quot; href=&quot;https://bugs.mojang.com/secure/attachment/148352/148352_stuck-repeater-clock.png&quot; title=&quot;stuck-repeater-clock.png&quot; file-preview-type=&quot;image&quot; file-preview-id=&quot;148352&quot; file-preview-title=&quot;stuck-repeater-clock.png&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/thumbnail/148352/_thumb_148352.png&quot; style=&quot;border: 0px solid black&quot; role=&quot;presentation&quot;/&gt;&lt;/a&gt;&lt;/span&gt; &lt;/li&gt;
&lt;/ol&gt;


&lt;h3&gt;&lt;a name=&quot;Whythishappens&quot;&gt;&lt;/a&gt;Why this happens&lt;/h3&gt;
&lt;p&gt;That happens because when you move away the chunks unload and so do the tile ticks of the repeaters. When you move closer again and the repeater that is in the chunk that was closer to you has a tile tick scheduled for turning on while the other has scheduled a tile tick for turning off, the chunk with the repeater that wants to turn on gets loaded first, the tile tick counts down and gets executed while the other repeater was not loaded the entire time and thus didn&apos;t yet turn off. Now both repeaters are turned on and the clock is broken.&lt;/p&gt;

&lt;p&gt;This is certainly not easy to fix. I think in order to fix this, tile ticks need to be overhauled in general. A system where tile ticks can be &quot;connected&quot; so that if one of them is loaded, the other gets loaded as well might be an option.&lt;/p&gt;</description>
                <environment></environment>
        <key id="11989">MC-711</key>
            <summary>Tile ticks of connected redstone components might be executed in the wrong order when unloading/reloading chunks</summary>
                <type id="1" iconUrl="https://bugs.mojang.com/secure/viewavatar?size=xsmall&amp;avatarId=18903&amp;avatarType=issuetype">Bug</type>
                                    <status id="4" iconUrl="https://bugs.mojang.com/images/icons/statuses/reopened.png" description="This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.">Reopened</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="Schortan">[Mod] NeunEinser</reporter>
                        <labels>
                            <label>chunk</label>
                            <label>redstone</label>
                            <label>reload</label>
                            <label>scheduled-block-updates</label>
                            <label>teleport</label>
                    </labels>
                <created>Fri, 26 Oct 2012 10:41:48 +0200</created>
                <updated>Wed, 21 Aug 2024 06:43:38 +0200</updated>
                                            <version>Minecraft 1.4.2</version>
                    <version>Minecraft 1.4.5</version>
                    <version>Minecraft 1.4.6</version>
                    <version>Minecraft 1.4.7</version>
                    <version>Snapshot 13w03a</version>
                    <version>Snapshot 13w04a</version>
                    <version>Snapshot 13w05a</version>
                    <version>Snapshot 13w05b</version>
                    <version>Snapshot 13w09b</version>
                    <version>Snapshot 13w09c</version>
                    <version>Snapshot 13w10a</version>
                    <version>Minecraft 1.5</version>
                    <version>Snapshot 13w11a</version>
                    <version>Minecraft 1.5.1</version>
                    <version>Minecraft 1.5.2</version>
                    <version>Minecraft 1.6.1</version>
                    <version>Minecraft 1.6.2</version>
                    <version>Minecraft 1.7.4</version>
                    <version>Minecraft 14w02c</version>
                    <version>Minecraft 14w03a</version>
                    <version>Minecraft 14w03b</version>
                    <version>Minecraft 1.7.9</version>
                    <version>Minecraft 14w20b</version>
                    <version>Minecraft 14w21a</version>
                    <version>Minecraft 14w21b</version>
                    <version>Minecraft 1.8</version>
                    <version>Minecraft 1.8.1-pre3</version>
                    <version>Minecraft 1.8.1</version>
                    <version>Minecraft 1.8.2-pre1</version>
                    <version>Minecraft 1.9.4</version>
                    <version>Minecraft 1.10</version>
                    <version>Minecraft 1.10.2</version>
                    <version>Minecraft 1.11.2</version>
                    <version>Minecraft 17w06a</version>
                    <version>Minecraft 1.12.2</version>
                    <version>Minecraft 17w43a</version>
                    <version>Minecraft 17w43b</version>
                    <version>Minecraft 18w03b</version>
                    <version>Minecraft 18w16a</version>
                    <version>Minecraft 1.13-pre2</version>
                    <version>Minecraft 1.13-pre3</version>
                    <version>Minecraft 1.13-pre6</version>
                    <version>Minecraft 1.13-pre7</version>
                    <version>Minecraft 1.13-pre8</version>
                    <version>Minecraft 1.13</version>
                    <version>Minecraft 18w31a</version>
                    <version>Minecraft 1.13.1-pre1</version>
                    <version>Minecraft 1.13.1-pre2</version>
                    <version>Minecraft 1.13.1</version>
                    <version>1.14.4</version>
                    <version>19w37a</version>
                    <version>19w38b</version>
                    <version>1.15.2</version>
                    <version>20w06a</version>
                    <version>20w07a</version>
                    <version>20w20b</version>
                    <version>20w21a</version>
                    <version>1.16.1</version>
                    <version>1.16.2</version>
                    <version>1.16.3</version>
                    <version>1.16.4</version>
                    <version>20w49a</version>
                    <version>20w51a</version>
                    <version>1.17.1</version>
                    <version>1.18.1</version>
                    <version>1.19.3</version>
                    <version>23w03a</version>
                    <version>23w04a</version>
                    <version>1.20.4</version>
                    <version>24w12a</version>
                    <version>24w33a</version>
                                    <fixVersion>Snapshot 13w10b</fixVersion>
                                                        <votes>150</votes>
                                    <watches>43</watches>
                                                                            <comments>
                            <comment id="1267218" author="JIRAUSER734481" created="Wed, 5 Jul 2023 17:55:02 +0200"  >&lt;p&gt;Can confirm in 1.20.1&lt;/p&gt;</comment>
                            <comment id="1234892" author="JIRAUSER734481" created="Wed, 1 Feb 2023 17:04:33 +0100"  >&lt;p&gt;Can confirm in 23w06a&lt;/p&gt;</comment>
                            <comment id="1233490" author="JIRAUSER734481" created="Wed, 25 Jan 2023 08:20:36 +0100"  >&lt;p&gt;Can confirm in 23w04a&lt;/p&gt;</comment>
                            <comment id="1221699" author="JIRAUSER734481" created="Wed, 18 Jan 2023 15:24:46 +0100"  >&lt;p&gt;Can confirm in 23w03a&lt;/p&gt;</comment>
                            <comment id="1221070" author="JIRAUSER734481" created="Sat, 14 Jan 2023 15:14:25 +0100"  >&lt;p&gt;Can confirm in 1.19.3&lt;/p&gt;</comment>
                            <comment id="1140749" author="JIRAUSER663810" created="Fri, 11 Feb 2022 02:25:42 +0100"  >&lt;p&gt;can confirm in 1.18.1&lt;/p&gt;</comment>
                            <comment id="1037511" author="JIRAUSER648933" created="Thu, 15 Jul 2021 17:13:14 +0200"  >&lt;p&gt;Can confirm in 1.17.1.&lt;/p&gt;</comment>
                            <comment id="899249" author="JIRAUSER506241" created="Tue, 19 Jan 2021 15:56:51 +0100"  >&lt;p&gt;Can confirm for 20w51a.&lt;/p&gt;</comment>
                            <comment id="744205" author="tpehep" created="Thu, 25 Jun 2020 17:56:55 +0200"  >&lt;p&gt;Can confirm for 1.16.1&lt;/p&gt;</comment>
                            <comment id="584633" author="schortan" created="Wed, 18 Sep 2019 13:01:57 +0200"  >&lt;p&gt;&lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=FaRo1&quot; class=&quot;user-hover&quot; rel=&quot;FaRo1&quot;&gt;FaRo1&lt;/a&gt; I can still reproduce the issue with the steps from above. Because of the aggressive unloading in 1.14, you don&apos;t even need to trigger an autosave&lt;/p&gt;

&lt;p&gt;Another setup related to this bug is this:&lt;br/&gt;
 &lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;a id=&quot;237505_thumb&quot; href=&quot;https://bugs.mojang.com/secure/attachment/237505/237505_2019-09-18_12.47.35.png&quot; title=&quot;2019-09-18_12.47.35.png&quot; file-preview-type=&quot;image&quot; file-preview-id=&quot;237505&quot; file-preview-title=&quot;2019-09-18_12.47.35.png&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/thumbnail/237505/_thumb_237505.png&quot; style=&quot;border: 0px solid black&quot; role=&quot;presentation&quot;/&gt;&lt;/a&gt;&lt;/span&gt; &lt;br/&gt;
The repeater on the left is placed towards the negative x, the other one to the positive x. The 2 repeaters on the left are on one tick, the one on the right on two ticks.&lt;br/&gt;
Usually the command block on the right will trigger first, because the tile tick of the 2-tick repeater scheduled first.&lt;br/&gt;
If you pause the game at the exact moment when the first 1-tick repeater is activated, but none of the others and then Save &amp;amp; Quit, the activation order will differ.&lt;/p&gt;</comment>
                            <comment id="584561" author="nighter" created="Wed, 18 Sep 2019 09:29:21 +0200"  >&lt;p&gt;Is this still an issue in 1.14.4 or later?&lt;/p&gt;</comment>
                            <comment id="505718" author="farogaming" created="Sat, 8 Dec 2018 22:00:05 +0100"  >&lt;p&gt;I&apos;m unable to reproduce, even though I think I&apos;ve seen it recently. Does someone know a reliable way to reproduce it?&lt;/p&gt;</comment>
                            <comment id="411149" author="schortan" created="Fri, 6 Oct 2017 00:43:05 +0200"  >&lt;p&gt;Oh thank you!&lt;br/&gt;
I updated the description with what I found out. &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="411055" author="miwob" created="Thu, 5 Oct 2017 18:57:48 +0200"  >&lt;p&gt;&lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=Schortan&quot; class=&quot;user-hover&quot; rel=&quot;Schortan&quot;&gt;Schortan&lt;/a&gt;: ticket is yours now. Please update it accordingly. Thanks!&lt;/p&gt;</comment>
                            <comment id="411054" author="schortan" created="Thu, 5 Oct 2017 18:53:08 +0200"  >&lt;p&gt;I can confirm for 1.12.2 and I am very confident that I know when and why it happens.&lt;br/&gt;
To reproduce that bug, just set up an ordinary repeater clock. Make sure that the two repeaters are in &lt;b&gt;different chunks&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;Now move away so that one chunk is closer to you than the other. When you are far enough away and you cannot see any of the repeaters, press esc to trigger chunk unloading. When you now move closer again, you have a chance that the repeater clock is now stuck. For me it actually happened every time I tested it.&lt;br/&gt;
&lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;a id=&quot;148352_thumb&quot; href=&quot;https://bugs.mojang.com/secure/attachment/148352/148352_stuck-repeater-clock.png&quot; title=&quot;stuck-repeater-clock.png&quot; file-preview-type=&quot;image&quot; file-preview-id=&quot;148352&quot; file-preview-title=&quot;stuck-repeater-clock.png&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/thumbnail/148352/_thumb_148352.png&quot; style=&quot;border: 0px solid black&quot; role=&quot;presentation&quot;/&gt;&lt;/a&gt;&lt;/span&gt; &lt;/p&gt;

&lt;p&gt;The reason that happens is that the repeater in the chunk a little further away from you had a tick scheduled for turning off and the repeater that is closer to you for turning on. What happens is that the repeater with a tile tick scheduled for turning on loads and executes its tile tick while the other repeater is still unloaded and does not continue counting down it&apos;s tile tick until the first repeater turns of, causes block updates and thus load the unloaded chunk with the other repeater.  The repeater will than not turn off since it is receiving power.&lt;/p&gt;</comment>
                            <comment id="319289" author="farogaming" created="Mon, 4 Jul 2016 02:30:17 +0200"  >&lt;p&gt;I found through searching:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;&quot;the fact that I was using circular repeater/comparator clocks caused the apparently &apos;random&apos; behavior because the repeaters would only freeze at certain locations&quot;&lt;/li&gt;
	&lt;li&gt;&quot;I think being able to reproduce it is relative to positioning or area&quot;&lt;/li&gt;
	&lt;li&gt;&quot;I&apos;m not entirely sure it&apos;s coordinate-related, but then again, it very well could be&quot;&lt;/li&gt;
	&lt;li&gt;&quot;in the event that it actually does turn out to be reproducible at specific coordinates&quot;&lt;br/&gt;
Nobody is sure? Is that still the case? I also wasn&apos;t able to find a code analysis.&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="319286" author="farogaming" created="Mon, 4 Jul 2016 02:23:17 +0200"  >&lt;p&gt;Sorry if this was somewhere in the last 100+ comments already, but: Could it be location dependent? I reproduced this more than 50% of the time before, now I can&apos;t get it to ever happen, after I moved it.&lt;/p&gt;</comment>
                            <comment id="312249" author="farogaming" created="Thu, 9 Jun 2016 21:04:21 +0200"  >&lt;p&gt;Confirmed for 1.10.&lt;/p&gt;</comment>
                            <comment id="232458" author="dylan5797" created="Sat, 27 Jun 2015 04:15:49 +0200"  >&lt;p&gt;That wouldn&apos;t be my approach. Best way to implement that would be to add a gamerule or a way to enable and disable that feature, if it were added.&lt;/p&gt;</comment>
                            <comment id="232455" author="jar_" created="Sat, 27 Jun 2015 04:02:16 +0200"  >&lt;p&gt;&lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=Dylan5797&quot; class=&quot;user-hover&quot; rel=&quot;Dylan5797&quot;&gt;Dylan5797&lt;/a&gt;, not really. That would keep all chunks in large redstone maps loaded forever, which would result in massive lag. Chunks are unloaded for a reason.&lt;/p&gt;</comment>
                            <comment id="232449" author="dylan5797" created="Sat, 27 Jun 2015 03:36:33 +0200"  >&lt;p&gt;Why doesn&apos;t Minecraft just summon an invisible entity for all the redstone components that can keep redstone running, even if the chunk is unloaded. That would be a help to everyone.&lt;/p&gt;</comment>
                            <comment id="232447" author="dylan5797" created="Sat, 27 Jun 2015 03:26:20 +0200"  >&lt;p&gt;Why don&apos;t you have a main teleport station where you set the world spawnpoint by using /setworldspawn. That means that your teleport station will always be loaded, even if you are in another dimention. All the other teleport stations can use the /setblock command to place a redstone block at the main station, which can teleport the player and reset the station the player used.&lt;/p&gt;

&lt;p&gt;I just thought if this still mattered to you, this can be a workaround.&lt;/p&gt;</comment>
                            <comment id="217600" author="thetamedwolf" created="Sat, 31 Jan 2015 04:19:53 +0100"  >&lt;p&gt;@Mods I don&apos;t know if this has anything to do with it but if the redstone clock is on the edge of a chunk and takes up space in two chunks, this has a higher chance of happening. and in two of my experiments, two of the failed clocks were on chunk coords 0,0,0 of whatever chunk it was in. I was looking at chunks 150 and 149. I took pictures and attached them. I was unable to get this to replicate with hoppers though. Something cause them to either duplicate items randomly or with using unstackable items,, the item goes super fast that the comparator doesn&apos;t have time to react.&lt;/p&gt;</comment>
                            <comment id="217599" author="thetamedwolf" created="Sat, 31 Jan 2015 04:18:51 +0100"  >&lt;p&gt;All of the powered ones stayed powered/&lt;br/&gt;
The ones that look off are running&lt;br/&gt;
The picture with two, they are both in two different chunks but the bottom one is oriented differently.&lt;br/&gt;
Also 2 of the failed clocks are setting on 0,0,0 of their respective chunk. I don&apos;t know if that is just a coincidence or if it really does have something to do with it all. I did the second one purpose and it stopped right away (after flying a long distance and tried one with tp far away)&lt;/p&gt;

&lt;p&gt;Hope this is of some use.&lt;/p&gt;</comment>
                            <comment id="214934" author="rubisk" created="Sun, 4 Jan 2015 22:00:17 +0100"  >&lt;p&gt;Confirmed of 1.8.2-pre1.&lt;/p&gt;

&lt;p&gt;Here&apos;s a bunch of stuff that might help the developers out.&lt;/p&gt;

&lt;p&gt;1) Reloading the world doens&apos;t seem to cause any issues, redstone always continues.&lt;/p&gt;

&lt;p&gt;2) Running away from the chunks, the walking back, causes all the 20Hz redstone clocks to stop. It will stop all redstone clocks if you unload at the right tick.&lt;/p&gt;

&lt;p&gt;3) Teleporting away from the chunks, then teleporting back, causes a specific position of redstone clocks to stop. Every chunk seems to have some sort of binary yes/no value, that defines whether or not a redstone clock stops if unloaded in the correct tick when you teleport away. &lt;a href=&quot;http://imgur.com/pqnreZg&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://imgur.com/pqnreZg&lt;/a&gt; this is a visualisation of all chunks that stop. Wherever water spilled, clocks in that chunk stopped. The most bottomleft chunk is (-1,-1), going up X to the left and up Z upwards. Notice that wherever chunkPosX = chunkPosZ the clocks do not stop.&lt;/p&gt;

&lt;p&gt;How to reproduce: Setup a 20hz fill clock. Put two command blocks on it. One sets a block to flowing water, somewhere up in the air. Surround the flowing water by glass on all corresponding Y positions to prevent it from spilling to the sides. The second command block sets the block below the flowing_water block to air. Whenever the fill clock stops running, the water spills everywhere.&lt;/p&gt;

&lt;p&gt;Something else to note, according to the command block output, it seems that redstone updates process one tick after the chunk blocks unload. This causes all redstone activity to give a &quot;can&apos;t access stuff outside the world&quot; error, and so the clock stops. If the clock continues, the redstone is saved as a tiletick (like it should), but if it stops, the command blocks show the &quot;can&apos;t access stuff outside the world error&quot;, and only the water gets saved as a tiletick. I&apos;ve been digging in the decompiled code for a bit, but my java knowledge isn&apos;t good enough to really find out what&apos;s causing this behavior.&lt;/p&gt;</comment>
                            <comment id="166137" author="kyletheboss95" created="Sat, 21 Jun 2014 06:36:25 +0200"  >&lt;p&gt;Ahh yes, I have seen this bug in my 1.7.2 map. &lt;/p&gt;</comment>
                            <comment id="161214" author="marcono1234" created="Sun, 1 Jun 2014 16:38:47 +0200"  >&lt;p&gt;Confirmed for 14w21b using &quot;&lt;a href=&quot;https://bugs.mojang.com/browse/MC-711&quot; title=&quot;Tile ticks of connected redstone components might be executed in the wrong order when unloading/reloading chunks&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-711&quot;&gt;MC-711&lt;/a&gt; Redstone Bug Test.zip&quot;&lt;br/&gt;
&lt;cite&gt;tp @p ~500000 ~ ~&lt;/cite&gt;&lt;br/&gt;
&lt;cite&gt;(wait a few seconds)&lt;/cite&gt;&lt;br/&gt;
&lt;cite&gt;tp @p ~-500000 ~ ~&lt;/cite&gt;&lt;br/&gt;
&lt;cite&gt;Some of the circuits will stop working.&lt;/cite&gt;&lt;/p&gt;

&lt;p&gt;*Added screenshot&lt;/p&gt;</comment>
                            <comment id="161197" author="jespertheend" created="Sun, 1 Jun 2014 15:00:31 +0200"  >&lt;p&gt;I&apos;ve not seen this bug in a long time, but I&apos;m pretty sure it&apos;s not fixed. Though I can&apos;t confirm that.&lt;/p&gt;</comment>
                            <comment id="161187" author="ezekielelin" created="Sun, 1 Jun 2014 14:37:51 +0200"  >&lt;p&gt;Is this still a concern in the latest Minecraft version &lt;b&gt;14w21b&lt;/b&gt;? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.&lt;/p&gt;</comment>
                            <comment id="132633" author="sg2000" created="Sat, 18 Jan 2014 17:48:31 +0100"  >&lt;p&gt;Confirmed for 14w03b using &quot;&lt;a href=&quot;https://bugs.mojang.com/browse/MC-711&quot; title=&quot;Tile ticks of connected redstone components might be executed in the wrong order when unloading/reloading chunks&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-711&quot;&gt;MC-711&lt;/a&gt; Redstone Bug Test.zip&quot;&lt;/p&gt;

&lt;p&gt;tp @p ~500000 ~ ~&lt;br/&gt;
(wait a few seconds)&lt;br/&gt;
tp @p ~-500000 ~ ~&lt;/p&gt;

&lt;p&gt;Some of the circuits will stop working.&lt;/p&gt;

&lt;p&gt;EDIT: Not sure how/if I&apos;m able to update the affected versions...&lt;/p&gt;</comment>
                            <comment id="86278" author="wolfiemario" created="Mon, 8 Jul 2013 20:13:12 +0200"  >&lt;p&gt;Confirmed for 1.6.2; I&apos;m starting to resort to abusing chunk loading bugs as a workaround to this issue.&lt;/p&gt;</comment>
                            <comment id="68527" author="wolfiemario" created="Sat, 25 May 2013 01:36:13 +0200"  >&lt;p&gt;Confirmed for 1.5.2; haven&apos;t tested on the snapshots.&lt;/p&gt;</comment>
                            <comment id="68517" author="mike10221999" created="Sat, 25 May 2013 01:06:54 +0200"  >&lt;p&gt;Jeb thinks he&apos;s fixed it. idk I haven&apos;t tested the dev versions.&lt;/p&gt;</comment>
                            <comment id="68516" author="mike10221999" created="Sat, 25 May 2013 01:05:48 +0200"  >&lt;p&gt;@John Stewart &lt;/p&gt;

&lt;p&gt;I have&lt;/p&gt;</comment>
                            <comment id="68508" author="kr1alpha" created="Sat, 25 May 2013 00:31:57 +0200"  >&lt;p&gt;I&apos;m haven&apos;t experienced this bug in the past month (or since 1.5.2). Is anyone else still experiencing this issue?&lt;/p&gt;</comment>
                            <comment id="61282" author="mike10221999" created="Fri, 19 Apr 2013 15:38:48 +0200"  >&lt;p&gt;Snapshot 13w10b did not fix this issue.&lt;/p&gt;</comment>
                            <comment id="61281" author="mike10221999" created="Fri, 19 Apr 2013 15:37:07 +0200"  >&lt;p&gt;Here&apos;s what happens to me:&lt;/p&gt;

&lt;p&gt;When I make a redstone machine that repeats itself over and over it freezes wnhen the chunks are  unloaded.It also happens on a mac.&lt;/p&gt;</comment>
                            <comment id="61277" author="mike10221999" created="Fri, 19 Apr 2013 15:28:32 +0200"  >&lt;p&gt;Someone please add Mac to the environment list.&lt;/p&gt;</comment>
                            <comment id="60064" author="wolfiemario" created="Fri, 12 Apr 2013 21:48:11 +0200"  >&lt;p&gt;MCedit indicates that the clocks are frozen once the chunks are unloaded, rather than upon reload: teleporting, and then saving and quitting, and opening the world in MCedit shows a sight identical to what you would see upon teleporting back.&lt;/p&gt;

&lt;p&gt;It should be noted that tileticks do not get saved properly for the clocks which freeze. All healthy clocks have at least one tiletick per repeater - some, strangely, can have two tileticks on a single repeater. A clock with only a single repeater bearing tileticks, or none at all, will be frozen, and MCedit will already render all its redstone as active. My record appears to be five tileticks in a single clock (one repeater has two, the other has three), and this clock is healthy and runs a half-tick pulse.&lt;/p&gt;

&lt;p&gt;Why so many tileticks are saved for some blocks, and none at all for others, I do not know. Apparently tiletick saving is asynchronous? Perhaps, when a chunk is to be unloaded, all activity in that chunk should stop before attempting to save any tileticks? I.e. does it stop processing ticks in the chunk altogether before attempting to save it to disk?&lt;/p&gt;</comment>
                            <comment id="60063" author="mike10221999" created="Fri, 12 Apr 2013 21:46:39 +0200"  >&lt;p&gt;This is also a problem on Mac to.&lt;/p&gt;</comment>
                            <comment id="60061" author="mike10221999" created="Fri, 12 Apr 2013 21:46:10 +0200"  >&lt;p&gt;I&apos;m glad that Mojang finally reopened this.&lt;/p&gt;</comment>
                            <comment id="60060" author="bljat" created="Fri, 12 Apr 2013 21:42:05 +0200"  >&lt;p&gt;Confirmed with the attached world.&lt;/p&gt;</comment>
                            <comment id="60056" author="wolfiemario" created="Fri, 12 Apr 2013 21:22:59 +0200"  >&lt;p&gt;It&apos;s not as detailed as The.Modificator&apos;s test, but it shows the bug. Use the command block to teleport far away, and then back, and you&apos;ll find a seemingly random number of clocks have frozen. The clocks which freeze varies each time you try.&lt;/p&gt;

&lt;p&gt;This time, all clocks freeze in powered state: there are no clocks which freeze to an unpowered state.&lt;/p&gt;</comment>
                            <comment id="60049" author="wolfiemario" created="Fri, 12 Apr 2013 20:42:55 +0200"  >&lt;p&gt;Confirmed for 1.5.1 Vanilla Singleplayer - this bug is not actually fixed. I&apos;ll upload a demonstration world shortly, but I am unable to devise a pattern in the bug&apos;s occurrence - it seems more likely at chunk borders, but can occur anywhere within a chunk as well.&lt;/p&gt;</comment>
                            <comment id="59043" author="zedarean" created="Sat, 6 Apr 2013 13:23:53 +0200"  >&lt;p&gt;Sorry Gerrard for the late response. This has happened to me on single player maps and multiplayer maps, both of which were vanilla. It doesn&apos;t happen often, but I will attempt to upload a schematic the next time I encounter the issue. &lt;/p&gt;</comment>
                            <comment id="59016" author="shangen010" created="Sat, 6 Apr 2013 05:29:05 +0200"  >&lt;p&gt;@Gerrard Thanks &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; &lt;/p&gt;</comment>
                            <comment id="58870" author="jespertheend" created="Thu, 4 Apr 2013 22:40:22 +0200"  >&lt;p&gt;Can someone reopen this? this is still an issue in 1.5.1&lt;/p&gt;</comment>
                            <comment id="58588" author="wolfiemario" created="Wed, 3 Apr 2013 05:00:32 +0200"  >&lt;p&gt;@Megan At the top-right, click &quot;Stop watching this issue&quot;.&lt;/p&gt;</comment>
                            <comment id="58572" author="shangen010" created="Wed, 3 Apr 2013 01:45:04 +0200"  >&lt;p&gt;I finally came back to this thread but @Jesper I wasn&apos;t lagging at all my frames were better than usual but I stopped messing w/ redstone (because I accidentally deleted the world...). By the way is it possible for me to leave the thread that way I&apos;m not emailed about this because my problem is &quot;resolved&quot; by not using redstone...&lt;/p&gt;</comment>
                            <comment id="58166" author="wolfiemario" created="Sun, 31 Mar 2013 16:36:50 +0200"  >&lt;p&gt;I should mention that this bug is &lt;b&gt;not&lt;/b&gt; fixed in Bukkit, and many people like to play maps in Bukkit (one of the more appealing features, ahem, is preventing cheating).&lt;/p&gt;

&lt;p&gt;Stephen, are you in Bukkit, a vanilla server, or singleplayer? If it&apos;s not Bukkit, it may be worth Mojang&apos;s (and everyone&apos;s) time for you to create a world download containing some of the redstone. You can prune a copy of your world down to the effected chunks in MCedit if you don&apos;t want to share your whole world - just be sure there is a sample of frozen redstone in there.&lt;/p&gt;</comment>
                            <comment id="58153" author="jespertheend" created="Sun, 31 Mar 2013 15:28:49 +0200"  >&lt;p&gt;I&apos;ve not seen this happen in 1.5.1 but I do get a lot of messages of people who can&apos;t play my map anymore because the clocks stopped&lt;/p&gt;</comment>
                            <comment id="58140" author="zedarean" created="Sun, 31 Mar 2013 13:38:25 +0200"  >&lt;p&gt;This bug has not been fixed. All of my redstone clocks keep freezing in 1.5.1. It doesn&apos;t happen as often. It used to happen every time a chunk was reloaded, but now it seems fairly random. &lt;/p&gt;</comment>
                            <comment id="56635" author="mike10221999" created="Sat, 23 Mar 2013 19:22:40 +0100"  >&lt;p&gt;The odd thing is that they never fixed it...&lt;/p&gt;
</comment>
                            <comment id="55009" author="the.modificator" created="Mon, 18 Mar 2013 14:27:19 +0100"  >&lt;p&gt;I just found a frozen comparator clock (as shown in screenshot &quot;comparator-stuck.png) in a dedicated server world (version 1.5 for both client and server). I removed all chunks not related to the problem (with MCEdit) and uploaded a zipped version of the world as &quot;comparator-stuck.zip&quot;. The frozen comparator is located at 54/58/-31&lt;/p&gt;

&lt;p&gt;Unfortunatley I have absolutely no clue how to &lt;b&gt;re&lt;/b&gt;-produce this. It used to occur a few times before but always happens seemingly randomly. With the comparator clock cable lying on a chunk border my guess would be that it has to do something with unloading and loading chunks - especially with multiple players moving around in the world.&lt;/p&gt;

&lt;p&gt;I also have a feeling that this used to happen only when restarting the server. (And I also have a feeling that the chunks in which the comparator clock is located were not be loaded in the moment the server shut down.)&lt;/p&gt;

&lt;p&gt;This problem already used to occur before the change in 13w10b. This version 1.5 occurence proves that the 13w10b change did not help in this case though.&lt;/p&gt;</comment>
                            <comment id="53451" author="jespertheend" created="Fri, 15 Mar 2013 11:33:16 +0100"  >&lt;p&gt;sounds more like lagg then.&lt;/p&gt;</comment>
                            <comment id="52732" author="shangen010" created="Thu, 14 Mar 2013 03:28:50 +0100"  >&lt;p&gt;@Jesper It&apos;s just a single player world but the seed is 764906023386979050 and the Coordinates are x:-1538 y:56 z:98 (although the coordinates may not help much. It was on a super flat world and I was messing around wiht redstone so it wasn&apos;t redstone lag but after I teleported to a new chunk it didn&apos;t occur as often. @Raphael My bad I always forget to put things, it&apos;s not a desktop it&apos;s a laptop that is Windows 7. Plus I did try to reproduce this bug and the redstone still froze but not very long. The repeater signal kind of just stood still and then went the signal was further away but I&apos;ve fixed the problem a little.&lt;/p&gt;</comment>
                            <comment id="52336" author="jespertheend" created="Wed, 13 Mar 2013 19:10:55 +0100"  >&lt;p&gt;@megan can you give us with the map?&lt;/p&gt;</comment>
                            <comment id="52318" author="bahzur" created="Wed, 13 Mar 2013 18:27:42 +0100"  >&lt;p&gt;Im unable to recreate that, but this also seems to be not related to this bug, because your repeaters stop while youre still there.&lt;br/&gt;
With system i meant, are you using a normal desktop pc with Windows 7?&lt;/p&gt;</comment>
                            <comment id="52312" author="shangen010" created="Wed, 13 Mar 2013 18:08:25 +0100"  >&lt;p&gt;Well I&apos;m not exactly very good with computer so it took me a while to figure out how to use the clip board. so I went on word and I just pasted it onto word then I just copied it back to my clip board. I was in creative mode (so I forgot to mention that) My system? I have a Windows 7 if that&apos;s what you mean. I was just flying around and I wasn&apos;t teleporting. &lt;/p&gt;</comment>
                            <comment id="52309" author="bahzur" created="Wed, 13 Mar 2013 18:02:10 +0100"  >&lt;p&gt;@Megan:&lt;br/&gt;
Without teleporting?&lt;br/&gt;
And what is your system? That screenshot has an unusual resolution.&lt;/p&gt;</comment>
                            <comment id="52279" author="shangen010" created="Wed, 13 Mar 2013 16:58:36 +0100"  >&lt;p&gt;The repeaters still freeze in 1.5. for some strange reason. I read that it was fixed but it still doesn&apos;t seem to be fixed for me.&lt;/p&gt;</comment>
                            <comment id="52275" author="shangen010" created="Wed, 13 Mar 2013 16:49:53 +0100"  >&lt;p&gt;I&apos;m sorry to bother this thread but I&apos;m using 1.5 and it still seems to be happening to me constantly. Well really what happens is I attached a button to a block of stone. Then I put a redstone wire coming out of the block of stone and 21 repeaters following the wire. If I use a pressure plate button or trip wire the repeaters randomly freeze around the 10-15th repeater it gets a bit annoyting. Just saying and I&apos;ll attach a screenshot&lt;/p&gt;</comment>
                            <comment id="50287" author="bahzur" created="Wed, 6 Mar 2013 14:11:44 +0100"  >&lt;p&gt;(again) thx Jeb! &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/biggrin.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="50277" author="the.modificator" created="Wed, 6 Mar 2013 13:57:13 +0100"  >&lt;p&gt;Looks great! &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; It appears that &lt;a href=&quot;https://bugs.mojang.com/browse/MC-3259&quot; title=&quot;Long redstone wire does not update/behaves strange in newly loaded chunks&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-3259&quot;&gt;&lt;del&gt;MC-3259&lt;/del&gt;&lt;/a&gt; was fixed as well by fixing this. Thanks, Jeb!&lt;/p&gt;

&lt;p&gt;@Gerrard Lukacs: You&apos;re right - I didn&apos;t notice that in my demonstration world the command block with &quot;say 14&quot; was never triggerd when using the wire-only setup. However, I just realized that the cable is just too long to actually reach it. So another mystery solved. &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; Also thanks a lot for your great feedback.&lt;/p&gt;</comment>
                            <comment id="50255" author="saoryn" created="Wed, 6 Mar 2013 12:45:26 +0100"  >&lt;p&gt;No longer able to replicate the bug under 13w10b. My hero &amp;lt;3 &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/tongue.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="49939" author="jeb" created="Tue, 5 Mar 2013 10:54:24 +0100"  >&lt;p&gt;Thanks for the help. I was able to use The.Modificator&apos;s world and stop the random behavior. Problem turned out to be that when ticks are scheduled, they are thrown away if the neighboring chunks haven&apos;t been loaded yet. Removing this check fixed the problem, and I couldn&apos;t discover any new errors.&lt;/p&gt;

&lt;p&gt;I&apos;m marking this as resolved, please reopen it if the bug occurs again in the next snapshot.&lt;/p&gt;</comment>
                            <comment id="49848" author="wolfiemario" created="Tue, 5 Mar 2013 02:13:24 +0100"  >&lt;p&gt;The.Modificator, you sir are a gentleman and a scholar. I can reproduce your behavior completely on my computer; I see I was wrong to figure it had anything to do with lag (perhaps the fact that I was using circular repeater/comparator clocks caused the apparently &quot;random&quot; behavior because the repeaters would only freeze at certain locations, and the fact that I was teleporting pretty much continuously back and forth meant the chunks did not always unload). Your world download has a 100% reproduction rate for me - this will almost certainly help Jeb fix the bug, as you&apos;ve sequestered it and analyzed its mechanics.&lt;/p&gt;

&lt;p&gt;I should note, however, that the pure redstone wire test does not trigger all command blocks, as you said it did - the fourteenth never triggered. Fortunately, this is the same for me as it is for you - the bug&apos;s consistent.&lt;/p&gt;</comment>
                            <comment id="49816" author="bakape" created="Tue, 5 Mar 2013 00:59:54 +0100"  >&lt;p&gt;I have a map with 100% reproduction rate. I saved next to the clock.  Just cut and reconnect the redstone wire to the repeater in question. Then grab the nearby boat and go far enough to unload the entire clock. After returning a repeater is always stuck in unpowered. &lt;br/&gt;
&lt;a href=&quot;https://www.dropbox.com/s/j3wahkk8l0nky1z/Copy%20of%20Jamen.zip?m&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://www.dropbox.com/s/j3wahkk8l0nky1z/Copy%20of%20Jamen.zip?m&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="49811" author="the.modificator" created="Tue, 5 Mar 2013 00:28:18 +0100"  >&lt;p&gt;Video upload and (first stage) processing complete; you can watch the video here: &lt;a href=&quot;https://youtu.be/95fuuajDQMc&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://youtu.be/95fuuajDQMc&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="49736" author="the.modificator" created="Mon, 4 Mar 2013 22:05:10 +0100"  >&lt;p&gt;Confirmed not fixed for 13w10a. Here&apos;s a (pretty long) video demonstrating the bug: &lt;a href=&quot;https://youtu.be/95fuuajDQMc&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://youtu.be/95fuuajDQMc&lt;/a&gt; &lt;del&gt;(At the moment of posting this, the upload is still in progress. The video should be up at around 00:20 UTC+1.)&lt;/del&gt;&lt;/p&gt;

&lt;p&gt;After watching the video you can try to reproduce the bug in my test world which I attached to this ticket.&lt;/p&gt;</comment>
                            <comment id="49727" author="hfog" created="Mon, 4 Mar 2013 21:53:31 +0100"  >&lt;p&gt;@Aikar: Be very careful with that. Triggering physics on chunk load runs the real risk of breaking a lot of devices, since it would mean triggering block updates for no reason other than that the chunk loaded. A better solution would be to defer unloading a chunk until all redstone behavior is in a safe state.&lt;/p&gt;</comment>
                            <comment id="49689" author="aikar" created="Mon, 4 Mar 2013 20:56:33 +0100"  >&lt;p&gt;couldnt triggering physics on chunk load essentially fix this?&lt;/p&gt;</comment>
                            <comment id="49602" author="wolfiemario" created="Mon, 4 Mar 2013 17:37:48 +0100"  >&lt;p&gt;Jason, you may want to upload a zip of your world for Jeb to test, in the event that it actually does turn out to be reproducible at specific coordinates.&lt;/p&gt;</comment>
                            <comment id="49596" author="saoryn" created="Mon, 4 Mar 2013 17:21:27 +0100"  >&lt;p&gt;Just in case it happens to help Jens, here&apos;s how I&apos;m seeing it: &lt;a href=&quot;http://i.cubeupload.com/HzZHSv.png&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://i.cubeupload.com/HzZHSv.png&lt;/a&gt; (ignore the background, this is the only place I can reproduce). I think being able to reproduce it is relative to positioning or area, I just have no idea what the conditions are. The reason I think that is because I have several more clocks a couple of hundred blocks or so away (-30, 64, -7 should that matter), that have never ever broken. I&apos;ve been able to place a clock within around a 50 block radius from the position shown on the screen, a few levels higher or lower too, and I&apos;ve been able to break it everytime. In order to break I just teleport to and from unloaded chunks a few times and it eventually breaks. For example I&apos;ll teleport to -500 64 -500, then 500 64 500 then teleport back to the clocks. If they&apos;re not broken I then teleport to -600 64 -600 then 600 64 600, then return and repeat this process as necessary. Though I am able to break clocks in the general area of the screenshot every single time by doing this eventually, as I said before the clocks in the other position have never broken at all, despite the fact they&apos;re rather close.&lt;/p&gt;</comment>
                            <comment id="49587" author="hfog" created="Mon, 4 Mar 2013 16:58:06 +0100"  >&lt;p&gt;My method for reproducing this: create a simple redstone repeater clock. A bunch of repeaters in a circle set to 4 ticks with a simple pulse injector to get them going should do the trick. Now leave the chunk (I usually see it by entering the nether and reentering the world in a different chunk). Go back and every now and then the clock will no longer be operating.&lt;/p&gt;

&lt;p&gt;It doesn&apos;t always happen. On 13w09c, I&apos;m seeing it only rarely.&lt;/p&gt;</comment>
                            <comment id="49582" author="wolfiemario" created="Mon, 4 Mar 2013 16:38:00 +0100"  >&lt;p&gt;Have you been able to try this on a computer under severe strain, or a fairly low-performance computer? I&apos;ve noticed I only get the bug when I &lt;em&gt;try&lt;/em&gt; to force my computer to its limits (to the point that &quot;Server can&apos;t keep up! Did the system time change?&quot; messages are being spammed) - I have yet to witness it when there was no lag. The problem is, it becomes more and more likely the more people are on my server (I&apos;ll try hosting Super Craft Brothers again in 1.5, as I&apos;ve noticed it happen quite a bit there; the repeaters don&apos;t fully discharge at the end of a match before everyone dies, and they stay frozen active once we return to that map, breaking it).&lt;/p&gt;</comment>
                            <comment id="49574" author="jeb" created="Mon, 4 Mar 2013 16:13:42 +0100"  >&lt;p&gt;I can&apos;t reproduce this. Tried both SMP and SSP, building those examples with command blocks within a chunk. The order of the say commands is unpredictable, but that&apos;s because the order in which repeaters are triggered is undefined if they all get the power at the same tick.&lt;/p&gt;

&lt;p&gt;Let&apos;s keep this open for the 10a snapshot.&lt;/p&gt;</comment>
                            <comment id="49165" author="buster_the_dog" created="Sat, 2 Mar 2013 20:53:19 +0100"  >&lt;p&gt;happens on windows vista also&lt;/p&gt;</comment>
                            <comment id="49164" author="buster_the_dog" created="Sat, 2 Mar 2013 20:52:01 +0100"  >&lt;p&gt;it said this was fixed in 13w09c, but it&apos;s not&lt;/p&gt;</comment>
                            <comment id="49016" author="the.modificator" created="Sat, 2 Mar 2013 13:52:31 +0100"  >&lt;p&gt;I did some more experiments concerncing this issue. I managed to create a pretty simple showcase where you can get some redstone components to get &quot;stuck&quot; easily:&lt;/p&gt;

&lt;p&gt;Create a setup like in &quot;chunk-middle-problem-01-basic-setup-repeaters.png&quot;. (Note: Make sure to build everything inside a single chunk - marking the edges helps!) Set the command block on the very right to teleport you very far away (at least 10 chunks). Set all other command blocks to trigger &quot;say&quot; commands as shown on the screenshot. &lt;b&gt;Edit:&lt;/b&gt; Make sure that the random chunk where you build this is very far away from the spawn as the chunks around the spawn will constantly stay loaded. The problem won&apos;t appear there! Teleporting 10000 blocks away from the spawn should bring you far away enough for this.&lt;/p&gt;

&lt;p&gt;Stand inside the chunk and then push the button. You&apos;ll notice that even though you were teleported away (which means that the teleportation command block must have got fired), not all command blocks in the chunk got fired. Only the &quot;say&quot; command blocks 1-7 were fired (as you can see on the chat window).&lt;/p&gt;

&lt;p&gt;When returning to the chunk, you&apos;ll see something like in chunk-middle-problem-02-repeaters-behavior.png. All repeaters &quot;behind the chunk&apos;s middle&quot; got stuck - which explains why the command blocks were not fired. (Side note: I had actually discovered this chunk middle problem in a different context before and reported it in &lt;a href=&quot;https://bugs.mojang.com/browse/MC-8194&quot; title=&quot;Redstone signal propagates very strangely in unloaded chunks&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-8194&quot;&gt;&lt;del&gt;MC-8194&lt;/del&gt;&lt;/a&gt;. The teleportation issue is a new context and therefore another problem type though.)&lt;/p&gt;

&lt;p&gt;You can also build other kinds of signal transmission methods as shown in the following screenshots - with similar strange effects. (Only the &quot;wire only&quot; transmission method seems to work. The shuffled command block firing order you encounter there might not be considered a real bug because all redstone wire elements could be expected to get fired at the very same time - which makes the firing order undefined and therefore allows a random order.)&lt;/p&gt;</comment>
                            <comment id="48939" author="kr1alpha" created="Sat, 2 Mar 2013 03:49:49 +0100"  >&lt;p&gt;Still experiencing the same issue as described on my Feb 1 post using Snapshot 13w09c in single player mode. Experienced two stuck stone buttons in 22 uses.&lt;/p&gt;</comment>
                            <comment id="48761" author="the.modificator" created="Fri, 1 Mar 2013 19:52:42 +0100"  >&lt;p&gt;This seems to be related to &lt;a href=&quot;https://bugs.mojang.com/browse/MC-3259&quot; title=&quot;Long redstone wire does not update/behaves strange in newly loaded chunks&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-3259&quot;&gt;&lt;del&gt;MC-3259&lt;/del&gt;&lt;/a&gt; - the underlying problem looks pretty similar: Some redstone components (especially repeaters but also comparators) don&apos;t update properly once a chunk gets loaded. A showcase for that problem can be seen in this video: &lt;a href=&quot;http://www.youtube.com/watch?v=e_MM97ifASw&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.youtube.com/watch?v=e_MM97ifASw&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="48739" author="sullytheunusual" created="Fri, 1 Mar 2013 18:35:37 +0100"  >&lt;p&gt;Confirmed not fixed in 13w09c SMP.&lt;/p&gt;</comment>
                            <comment id="48702" author="bljat" created="Fri, 1 Mar 2013 17:20:37 +0100"  >&lt;p&gt;Confirmed not fixed.&lt;/p&gt;</comment>
                            <comment id="48698" author="bakape" created="Fri, 1 Mar 2013 17:16:57 +0100"  >&lt;p&gt;Still occurring in 13w09c singleplayer survival. To reproduce I need to get far enough to unload my piston clock. After returning to the clock, a repeater is unpowered, although the redstone connected to it is. If you need any other info, comment and I shall provide it. &lt;/p&gt;</comment>
                            <comment id="48696" author="hfog" created="Fri, 1 Mar 2013 17:13:34 +0100"  >&lt;p&gt;Definitely still happening in 13w09c. Just walking far enough away from a chunk with a redstone clock in it can leave the clock broken.&lt;/p&gt;</comment>
                            <comment id="48679" author="grygrflzr" created="Fri, 1 Mar 2013 16:56:06 +0100"  >&lt;p&gt;Reopened.&lt;/p&gt;</comment>
                            <comment id="48677" author="bljat" created="Fri, 1 Mar 2013 16:52:58 +0100"  >&lt;p&gt;Unable to reproduce.&lt;br/&gt;
Edit: Neither in SSP nor in SMP.&lt;/p&gt;</comment>
                            <comment id="48662" author="saoryn" created="Fri, 1 Mar 2013 16:32:39 +0100"  >&lt;p&gt;Still occurring for me with 13w09c unfortunately &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/sad.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="48300" author="bahzur" created="Thu, 28 Feb 2013 13:53:03 +0100"  >&lt;p&gt;thx Jeb! &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/biggrin.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="48293" author="jeb" created="Thu, 28 Feb 2013 13:32:03 +0100"  >&lt;p&gt;I managed to reproduce it and then I managed to change stuff so I no longer was able to reproduce it... I don&apos;t know any other way to properly verify that the bug is gone, or that I haven&apos;t added new bugs =( Please re-open this in future snapshots if you&apos;re able to find it again.&lt;/p&gt;</comment>
                            <comment id="48043" author="wolfiemario" created="Wed, 27 Feb 2013 20:10:23 +0100"  >&lt;p&gt;Can somebody please update the version information? Mojang probably won&apos;t look at this if it&apos;s supposedly not in the current snapshots - and this is a &lt;em&gt;very&lt;/em&gt; bad bug to have for the 1.5 (pre)release tommorow.&lt;/p&gt;

&lt;p&gt;I can confirm this for a server on 13w09b, although it took a few tries. Yes, the server is vanilla.&lt;/p&gt;

&lt;p&gt;EDIT: Also, can the title be changed? It&apos;s misleading. In 13w09b, I managed to get a repeater clock to fully &lt;em&gt;depower&lt;/em&gt; from teleports.&lt;/p&gt;</comment>
                            <comment id="47243" author="saoryn" created="Sat, 23 Feb 2013 19:21:53 +0100"  >&lt;p&gt;@GrygrFlzr, unfortunately I am unable to replicate. Although my previous clock did border a chunk, I then moved it completely inside a chunk and teleported to and from, and the new clock still froze, yet the one I had problems with previously did not...&lt;/p&gt;</comment>
                            <comment id="47232" author="jespertheend" created="Sat, 23 Feb 2013 18:03:10 +0100"  >&lt;p&gt;but why do all the repeaters inside the chunk get stuck too then? You&apos;d expect them to all turn on/ all turn off&lt;/p&gt;</comment>
                            <comment id="47196" author="grygrflzr" created="Sat, 23 Feb 2013 11:58:45 +0100"  >&lt;p&gt;From what you&apos;re saying it seems like the redstone components are in-between chunk boundaries, which is known to cause problems.&lt;br/&gt;
I&apos;ve just tested it on the latest snapshot and this seems to be it.&lt;br/&gt;
Here&apos;s a video showing the problem: &lt;a href=&quot;http://www.youtube.com/watch?v=C5Zi6ErzdZ0&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.youtube.com/watch?v=C5Zi6ErzdZ0&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;EDIT:&lt;br/&gt;
Note that the problem isn&apos;t that the repeater is crossing a chunk - the problem is that the left pulsar is sitting right on the boundary of 4 different chunks.&lt;/p&gt;</comment>
                            <comment id="47192" author="jespertheend" created="Sat, 23 Feb 2013 11:00:32 +0100"  >&lt;p&gt;@jason That&apos;s exactly what I&apos;m experiencing.&lt;br/&gt;
try moving the clock 1 block, that fixes it sometimes.&lt;/p&gt;</comment>
                            <comment id="47064" author="saoryn" created="Fri, 22 Feb 2013 15:29:03 +0100"  >&lt;p&gt;Seems to be a random occurrence for me, and unrelated to how much my computer is doing. Strange thing for me is that I have several clocks in various places on a test map, yet it&apos;s only one specific clock that freezes, no matter how many times I replace the components. As I&apos;m sure is happening with others, if it occurs it completely breaks my adventure map, so hopefully a fix is in the works.&lt;/p&gt;</comment>
                            <comment id="46159" author="enchanteddiamond" created="Sun, 17 Feb 2013 00:14:53 +0100"  >&lt;p&gt;This still needs to be fixed, the problems that redstone is only saved in two ways On/Off so when a chunk is loaded the redstone which was on loads as on and off stays off and they stay that way (like mcediting water and lava nothing happens untill block update) anyway I found this happens for all type of redstone including detector rails and needs to be fixed before 1.5 update.&lt;/p&gt;</comment>
                            <comment id="45894" author="xcalzum" created="Fri, 15 Feb 2013 16:27:21 +0100"  >&lt;p&gt;I can confirm.&lt;/p&gt;</comment>
                            <comment id="44916" author="buster_the_dog" created="Sun, 10 Feb 2013 01:02:21 +0100"  >&lt;p&gt;this needs to be fixed or it will be the end of all adventure maps&lt;/p&gt;</comment>
                            <comment id="43124" author="bankstoneditor" created="Sun, 3 Feb 2013 15:59:45 +0100"  >&lt;p&gt;I do know that lag will affect block updates, as my desktop that my sisters have in their room (don&apos;t ask, its mine), when they run minecraft with the dozens of other background programs they have (I seriously regret getting a TV in my room...), their framerate is less than 5-6 fps on low render, regular lighting, etc. (you get the idea) and fluids, gravity blocks and redstone won&apos;t update reliably, or not even at all.&lt;/p&gt;

&lt;p&gt;(Sorry about the ranting... my sisters seriously messed up my desktop. They even admitted that they get the Blus Screen of Death (windows crash screen) every day)&lt;/p&gt;</comment>
                            <comment id="43116" author="wolfiemario" created="Sun, 3 Feb 2013 15:48:17 +0100"  >&lt;p&gt;Yeah, that&apos;s what I think too. I&apos;m not entirely sure it&apos;s coordinate-related, but then again, it very well could be (my testing clocks had many different repeaters; I can&apos;t be sure whether any one &lt;em&gt;did&lt;/em&gt; freeze on one test but didn&apos;t on another).&lt;/p&gt;

&lt;p&gt;At any rate, it still seems performance related for me - What happens if you lag your computer by running several instances of Minecraft? Does it make the bug more likely for you too? What about the rate on a server compared to the rate in singleplayer?&lt;/p&gt;</comment>
                            <comment id="43070" author="jespertheend" created="Sun, 3 Feb 2013 10:47:53 +0100"  >&lt;p&gt;I think some blocks just won&apos;t have a tile tick, because if I move the block one block to the right it doesn&apos;t get stuck, so the position of a tile tick has something to do with it. So sometimes one repeater gets updated, but another (since it&apos;s on another position) doesn&apos;t get updated, causing the clock to be fully powered (or not). And if a clock just completely freezes (one half powered, one half not powered) That&apos;s because both tile tick&apos;s aren&apos;t saved.&lt;/p&gt;</comment>
                            <comment id="42892" author="wolfiemario" created="Sat, 2 Feb 2013 19:19:34 +0100"  >&lt;p&gt;Yeah, that can&apos;t be it, because sometimes components freeze altogether - they never get updated. Also, tile ticks are scheduled events - they have a timer indicating when they should be activated; not every tick is meant to activate the moment a chunk loads (slow things such as max-delay repeaters and flowing lava come to mind).&lt;/p&gt;

&lt;p&gt;While your theory seems plausible in some cases, it doesn&apos;t match everything I&apos;ve observed: I have seen a very large repeater loop, with a very large pulse (consuming almost the entire loop) get shortened to a two-repeater pulse, because the leading edge froze and the trailing edge went through the loop until it caused a redstone update to the leading edge. This is not simply a matter of asynchronous loading; the leading edge does not begin to move until it gets a redstone update from the trailing edge.&lt;/p&gt;</comment>
                            <comment id="42865" author="jespertheend" created="Sat, 2 Feb 2013 18:05:38 +0100"  >&lt;p&gt;I don&apos;t think the tile ticks are saved wrongly or something, but I think the problem is that as soon as a chunk gets loaded, the tile ticks are loaded to, but they are not all loaded at the same time, so when you have a simple repeater clock, one repeater gets updated, powering the redstone it is pointing at. And one repeater gets updated too late, so the redstone behind him is already on. In the end all the redstone is powered.&lt;br/&gt;
Although this might not be the case, because I&apos;ve also seen a clock that just was stuck. So a repeater had redstone in the on state behind him, but it didn&apos;t get powered.&lt;/p&gt;</comment>
                            <comment id="42610" author="wolfiemario" created="Sat, 2 Feb 2013 01:29:57 +0100"  >&lt;p&gt;Yeah, forcing updates to all redstone elements in a chunk upon loading would be a bad idea. For one, Tile Ticks can be scheduled: e.g., a repeater with a delay isn&apos;t meant to cause a redstone update until after its delay time is up. If you sent redstone updates to everything at once, this would still desynchronize timing-sensitive systems upon chunk loading: even if redstone would no longer freeze, complicated machines would still be damaged.&lt;/p&gt;

&lt;p&gt;Lag would also be an issue, as Raphael said: redstone updates actually propagate to about two blocks away from the block that&apos;s being updated - I&apos;m not entirely sure, but if everything updated at once, several objects may be updated multiple times in the process, due to an overlap in that 5x5x5 update cube - whether this would have worse consequences than lag, I do not know. At any rate, it would certainly be wasteful; if you have a long line of active repeaters, the ones in the middle do not need any updating - only the ones at the ends do.&lt;/p&gt;</comment>
                            <comment id="42597" author="bahzur" created="Sat, 2 Feb 2013 01:08:21 +0100"  >&lt;p&gt;That would produce massive lag. Thats what the tileticks are for, when the chunk unloads the tile tick save what blocks need to be updated when the chunk reloads.&lt;br/&gt;
The problem is that if the pc/server is under heavy load (which is the case most time you play minecraft), many redstone tile ticks arent saved.&lt;br/&gt;
Read Gerrards comment above, he already explained it.&lt;/p&gt;</comment>
                            <comment id="42588" author="howzieky" created="Sat, 2 Feb 2013 00:42:11 +0100"  >&lt;p&gt;Yeah Cody! That would work! I think...&lt;/p&gt;</comment>
                            <comment id="42586" author="stuckurface" created="Sat, 2 Feb 2013 00:36:36 +0100"  >&lt;p&gt;@Raphael&lt;br/&gt;
Couldn&apos;t it be done so that when the chunks reload, they update all the blocks in the chunk.&lt;/p&gt;</comment>
                            <comment id="42544" author="bahzur" created="Fri, 1 Feb 2013 22:51:11 +0100"  >&lt;p&gt;@Cody:&lt;br/&gt;
It already does that. The problem is, it doesnt update the state when the chunks load. Like, it forgot that theres redstone that was working when the chunk unloaded and now it just stays on or off.&lt;/p&gt;</comment>
                            <comment id="42524" author="stuckurface" created="Fri, 1 Feb 2013 22:26:07 +0100"  >&lt;p&gt;I don&apos;t know too much about Java but, couldn&apos;t you just have it so that when a chunk has active redstone in it, it saves the on/off state of the redstone and then when the chunk reloads, it puts the redstone&apos;s on/off state back to what it was when it was unloaded?&lt;/p&gt;</comment>
                            <comment id="42487" author="kimitsu" created="Fri, 1 Feb 2013 20:48:33 +0100"  >&lt;p&gt;Chunk linking tool would be cool too. For instance, a special block: once chunk is loaded that block would ensure that one specific neigbor chunk is loaded as well. This would be useful for machinery that doesn&apos;t exactly need to be loaded all of the time, but is bigger than one chunk and needs to be loaded simultaniously in order to properly work.&lt;/p&gt;</comment>
                            <comment id="42464" author="wolfiemario" created="Fri, 1 Feb 2013 19:04:39 +0100"  >&lt;p&gt;I&apos;m not sure &quot;only the redstone of the chunk would be forced to load&quot; makes sense in the context of how Minecraft works. The only way for the game to tell where redstone exists in a chunk is to look at the blocks in the chunk, which would require loading the chunk. The only reason the game can choose what chunks to load is because it knows where to find each chunk - unless you created an &quot;index&quot; of what blocks in a chunk are redstone, there&apos;d be no way to &quot;partially load&quot; the chunk. And even if you did, this wouldn&apos;t cover special cases, such as pistons which can push ordinary blocks, which would in turn create their own block updates (consider an automatic cobblestone generator). I don&apos;t think it&apos;s possible to implement a &quot;load only the redstone&quot;, as redstone&apos;s very interconnected with the rest of the world - you&apos;d be bound to find dozens of bugs, which would be a major headache to fix.&lt;/p&gt;

&lt;p&gt;I think, if they let map makers force certain chunks to be loaded, it should apply to the whole chunk. This would also allow things such as minecarts to run, entities to age, items to despawn, etc. Regardless, letting mapmakers force certain chunks to always be loaded is not a fix to this bug. It is only a workaround, only works for mapmakers and server ops, and it&apos;s still possible that this bug would effect such chunks when closing and reopening the world/server (can somebody confirm whether this bug applies to the spawn chunk of your server during a restart?). The only actual purpose of letting mapmakers force chunks to stay loaded is for specific things you might want to build, such as a clock that&apos;s always running - such a feature should never be considered a solution to this bug.&lt;/p&gt;

&lt;p&gt;As far as actually fixing this bug, I think the proper move is to ensure that redstone devices &lt;b&gt;always&lt;/b&gt; save their Tile Ticks when their chunk is unloaded. Tile Ticks tell the game when a block or redstone update is supposed to happen in the future (or should have happened in the past and is overdue) once a chunk has been loaded: they are meant to save activity in a chunk, so things such as flowing water don&apos;t freeze just because a chunk got unloaded before the water flowed all the way. This bug appears to be happening because redstone Tile Ticks aren&apos;t always saved - particularly during periods of lag. If that can be corrected, this bug should finally be fixed.&lt;/p&gt;</comment>
                            <comment id="42457" author="johnkcraft" created="Fri, 1 Feb 2013 18:40:49 +0100"  >&lt;p&gt;Ah, so the solution would be the creator of the map to choose which chunks would be forced to carry, perhaps by block command, but instead of loading the entire chunk, only the redstone of the chunk would be forced to load. How about that?&lt;/p&gt;</comment>
                            <comment id="42448" author="wolfiemario" created="Fri, 1 Feb 2013 18:15:39 +0100"  >&lt;p&gt;That would be a very bad idea, as it would defeat the purpose of chunk loading on large redstone-heavy maps. Chunks are unloaded so your computer doesn&apos;t have to handle billions of blocks and thousands of entities at one time. If every chunk with redstone were loaded at all times, a map with a large amount of redstone would lag a lot, and consume excessive amounts of RAM. This also means a larger-than-normal amount of chunks must be loaded when starting up a map.&lt;/p&gt;

&lt;p&gt;However, I think it would be nice for map makers and server operators to choose for a chunk to be persistent: that is, force the chunk to be treated like the spawn chunk, and thus be active at all times. There are many neat things you can do by sticking certain redstone mechanics in the spawn chunk as it is, but these do not work in singleplayer (as far as I know). Either way, letting ops and map makers make chunks persistent wouldn&apos;t be a fix to this bug, it would be a different feature altogether, and would only be a workaround to this bug.&lt;/p&gt;

&lt;p&gt;Making persistence mandatory for redstone chunks, on the other hand, would indeed &quot;fix&quot; this bug, but it would only be a band-aid fix, and with horrible repercussions (also, chunks &lt;b&gt;have&lt;/b&gt; to be unloaded when your server or world is stopped, so this bug could still occur when restarting your server or world).&lt;/p&gt;</comment>
                            <comment id="42438" author="johnkcraft" created="Fri, 1 Feb 2013 17:47:08 +0100"  >&lt;p&gt;Gerrard Lukacs,&lt;br/&gt;
Thanks, but I understand this bug has not been fixed yet, why this is happening to you. And I have an idea to solve the problem: Minecraft could understand that chuncks that has redstone should never stops working, simple as that. What do you think?&lt;/p&gt;</comment>
                            <comment id="42432" author="wolfiemario" created="Fri, 1 Feb 2013 17:28:07 +0100"  >&lt;p&gt;I have noticed this happen in vanilla servers (the &quot;repeater freezing bug&quot;, which was supposedly fixed in 1.4.1, happens to me on vanilla servers occasionally when teleporting, but I have been unable to reproduce it in singleplayer. It seems the &quot;fix&quot; only drastically reduced the rate of this bug for repeaters (I don&apos;t know about other redstone components), as this used to happen a lot more frequently in both SMP and SSP before the &quot;fix&quot;).&lt;/p&gt;

&lt;p&gt;I should also mention that this bug seems to be tied to computer performance: The number of redstone components which freeze seems to vary; when my computer isn&apos;t under stress a repeater clock will usually not be effected at all. With a decent amount of stress (and it&apos;s hard to get the vanilla server to run without this being the case), there&apos;s a slight chance of the leading or trailing repeater in a loop becoming frozen, which can be observed by a repeater clock&apos;s pulse being shortened to a single active repeater or lengthened until the pulse is almost the size of the clock itself, respectively. When there&apos;s a lot of strain on my computer, a leading freeze becomes more likely, and it&apos;s possible to get both edges of the pulse to freeze (thus freezing the clock entirely).&lt;/p&gt;

&lt;p&gt;I have a feeling the reason this seems performance-related is because the bug occurs when a tileTicks is not saved as a chunk is unloading. I&apos;m not sure why, but it seems the game misses out on certain tileTicks it was meant to write, as though it&apos;s more in a hurry to unload the chunk than it is to make sure everything&apos;s written to it first.&lt;/p&gt;

&lt;p&gt;And Jo&#227;o, if you walk far away enough until the chunks are unloaded, then the clock cannot keep time because its chunks are unloaded and thus the redstone is not being processed. This is true both with and without this bug. With the existence of this bug, your clock is likely to eventually freeze and break down, requiring you to manually look over the redstone and find where the components have frozen (even uglier is the fact that this bug can cause major desynchronization, because it doesn&apos;t freeze &lt;em&gt;all&lt;/em&gt; components all the time). If this bug is fixed, then yes, your clock would continue from 18:27 operating normally. If you want it to continue from 18:30, you would be forced to build the entire clock within the spawn chunk, which never gets unloaded: only &lt;em&gt;then&lt;/em&gt; will it be constantly running and keeping time (incidentally, as it would never be unloaded, this glitch shouldn&apos;t ever effect it, unless it also happens during a server restart).&lt;/p&gt;</comment>
                            <comment id="42428" author="johnkcraft" created="Fri, 1 Feb 2013 17:20:10 +0100"  >&lt;p&gt;Oh yeah, thanks.&lt;/p&gt;</comment>
                            <comment id="42416" author="grygrflzr" created="Fri, 1 Feb 2013 17:01:08 +0100"  >&lt;p&gt;Jo&#227;o: Jasper means that this issue is confirmed to still exist in 13w05b.&lt;/p&gt;</comment>
                            <comment id="42413" author="johnkcraft" created="Fri, 1 Feb 2013 16:47:30 +0100"  >&lt;p&gt;Jesper the End,&lt;br/&gt;
you&apos;re saying that was fixed in 13w05b?&lt;br/&gt;
I saw nothing about this bug be fixed in the Mojang site.&lt;br/&gt;
And if it was fixed, I have a question, for example: I have a digital clock constructed into my server, it marks 18:27, I walk away 10 chunks him and stay there for 3 minutes, when back toward him, he will still be on 18:27 continuing operating normally, or scoring 18:30 already?&lt;/p&gt;</comment>
                            <comment id="42344" author="jespertheend" created="Fri, 1 Feb 2013 14:56:32 +0100"  >&lt;p&gt;confirmed for 13w05b&lt;/p&gt;</comment>
                            <comment id="42152" author="kr1alpha" created="Fri, 1 Feb 2013 02:12:35 +0100"  >&lt;p&gt;Issue still persists in Snapshot 13w05a. Reproduced the glitch/bug this time by quitting the game while standing next to a normally functioning stone button beneath command block. Then restarted the game and the same stone button was stuck in the depressed position.&lt;/p&gt;</comment>
                            <comment id="40321" author="jespertheend" created="Sun, 27 Jan 2013 15:20:37 +0100"  >&lt;p&gt;Here&apos;s some more information:&lt;br/&gt;
-It doesn&apos;t only happen when you teleport. Fly away from the redstone really far, then just quit to title, come back and then it is also broken.&lt;br/&gt;
-Apparently it does or doesn&apos;t occur depending on the position of the redstone, for example when I move a clock one block to the right, fly away, quit to title and come back it isn&apos;t broken, where it is broken if it is one block to the left.&lt;/p&gt;</comment>
                            <comment id="39880" author="bankstoneditor" created="Sat, 26 Jan 2013 00:04:08 +0100"  >&lt;p&gt;@Jesper I think the problem is that the redstone isn&apos;t sending the information to update in time before it unloads, because you can walk out of render distance and it will still run fine when you come back, but just jumping out of render distance is the problem. A long-term solution for Mojang could be having redstone, repeaters, comparators, torchs, etc update whenever it&apos;s chunk is loaded, though it would cause lag when rendering redstone-heavy chunks, it would fix this problem.&lt;br/&gt;
Or cause a delay before unloading a chunk to, like Jesper said, store where the update should be, but, again, lag is an issue here with chunks with a lot of redstone, and having a lot of chunks loaded at one time.&lt;br/&gt;
I am not sure about any other bugs that would come because of these aforementioned possible fixes, because I know nothing about Java and the Minecraft coding, but who knows?&lt;/p&gt;</comment>
                            <comment id="39797" author="jespertheend" created="Fri, 25 Jan 2013 18:36:02 +0100"  >&lt;p&gt;Ok I&apos;m no pro at programming, and I do not know how minecraft works. But can&apos;t you just store where a redstone update should be when a chunk unloads. Just like what happens when you save and quit.&lt;br/&gt;
It&apos;s the TAG_List &apos;TileTicks&apos; I believe.&lt;/p&gt;</comment>
                            <comment id="39784" author="jespertheend" created="Fri, 25 Jan 2013 17:24:59 +0100"  >&lt;p&gt;I feel sad now &lt;img class=&quot;emoticon&quot; src=&quot;https://bugs.mojang.com/images/icons/emoticons/sad.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;br/&gt;
@sam I tried that too but it didn&apos;t work. Probably because the comparator freezes too.&lt;/p&gt;</comment>
                            <comment id="39636" author="kr1alpha" created="Fri, 25 Jan 2013 04:26:04 +0100"  >&lt;p&gt;Also confirmed the glitch/bug still exists in 13w04a. Issue occurs once in every ten uses of the command block with /tp command. Stone buttons in the chunk with the &quot;stuck&quot; stone button still operated normally. Crash report located above-&lt;/p&gt;</comment>
                            <comment id="39632" author="stuckurface" created="Fri, 25 Jan 2013 03:50:32 +0100"  >&lt;p&gt;Confirmed in 13w04a&lt;/p&gt;</comment>
                            <comment id="39306" author="buster_the_dog" created="Wed, 23 Jan 2013 22:29:07 +0100"  >&lt;p&gt;I fixed this by using a comparator next to one of the redstone repeaters&lt;/p&gt;</comment>
                            <comment id="37739" author="nathan2055" created="Fri, 18 Jan 2013 02:36:56 +0100"  >&lt;p&gt;Duped it again at &lt;a href=&quot;https://bugs.mojang.com/browse/MC-7708&quot; title=&quot;Buttons lag when used to issue a /tp command&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-7708&quot;&gt;&lt;del&gt;MC-7708&lt;/del&gt;&lt;/a&gt;. For me, it &quot;freezes&quot; all button in the on position. A chunk update doesn&apos;t seem to help. Only thing I can do is remove the button and replace it. However, in some testcases it doesn&apos;t freeze, making this bug pretty random.&lt;/p&gt;</comment>
                            <comment id="36957" author="bankstoneditor" created="Tue, 15 Jan 2013 14:04:31 +0100"  >&lt;p&gt;In 13w02b, I have this problem, except when the chunks load for the first time when loading up the world, my redstone clocks would all stop, either on when it is a short clock, or off when it is a long clock (I use purely repeater and comparator clocks)...&lt;br/&gt;
I think this has to do with how the game freezes redstone when the chunk unloads, and it doesn&apos;t update when it reloads...&lt;br/&gt;
A temporary fix until then would probably be attaching a comparator from the newest snapshot to the area where it happens, since they give constant redstone updates to the block it&apos;s pointing at.&lt;/p&gt;</comment>
                            <comment id="29907" author="brandonn" created="Fri, 21 Dec 2012 15:27:34 +0100"  >&lt;p&gt;I have also reproduced this bug: &lt;a href=&quot;https://mojang.atlassian.net/browse/MC-5019&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://mojang.atlassian.net/browse/MC-5019&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="29346" author="sg2000" created="Tue, 18 Dec 2012 20:49:14 +0100"  >&lt;p&gt;Can confirm this.&lt;br/&gt;
Here&apos;s my force-crash report.&lt;br/&gt;
Will hopefully be fixed soon!&lt;/p&gt;

&lt;p&gt;(Crash report attached, see above.)&lt;/p&gt;</comment>
                            <comment id="29088" author="johnkcraft" created="Mon, 17 Dec 2012 17:52:47 +0100"  >&lt;p&gt;This bug will be fixed?&lt;/p&gt;</comment>
                            <comment id="16260" author="grygrflzr" created="Thu, 1 Nov 2012 08:41:01 +0100"  >&lt;p&gt;Which is why I used 10 as an example, as 10 is the default for vanilla servers. I don&apos;t think most servers would change it, let alone decrease it (increasing it makes more sense).&lt;/p&gt;</comment>
                            <comment id="16254" author="sycholic" created="Thu, 1 Nov 2012 08:22:03 +0100"  >&lt;p&gt;btw that work around is relative to the draw distance the server is set up for it can be low as 4 or high as 16chunks.&lt;/p&gt;</comment>
                            <comment id="14636" author="grygrflzr" created="Sun, 28 Oct 2012 07:42:27 +0100"  >&lt;p&gt;This is because the redstone unloads before it turns off again. A temporary work-around is to do multiple short jumps that still load the redstone, allowing it to turn off.&lt;br/&gt;
So instead of:&lt;br/&gt;
&lt;b&gt;Teleporter A&lt;/b&gt; ===tp 42 chunks==&amp;gt; &lt;b&gt;Place B&lt;/b&gt;&lt;br/&gt;
Do the following:&lt;br/&gt;
&lt;b&gt;Teleporter A&lt;/b&gt; ===tp 10 chunks==&amp;gt; Teleporter C ===tp 10 chunks==&amp;gt; Teleporter D ===tp 10 chunks==&amp;gt; Teleporter E ===tp 10 chunks==&amp;gt; Teleporter F ===tp 2 chunks==&amp;gt; &lt;b&gt;Place B&lt;/b&gt;&lt;br/&gt;
It&apos;s tedious, but you&apos;ll have to make do with it for now.&lt;/p&gt;</comment>
                            <comment id="14017" author="aeroshock" created="Fri, 26 Oct 2012 17:26:27 +0200"  >&lt;p&gt;I was having a similar problem in an earlier snapshot with a teleporter I&apos;d built. I had it set up so you had to stand on a pressure plate and hit a button simultaneously in order to trigger the command block, then when returning, sometimes either the button or the pressure plate were stuck in the &apos;on&apos; position, making the teleporter behave incorrectly. This would only happen when teleporting to a location far enough away that the server would unload the chunk the teleporter was in, but it wouldn&apos;t happen every time, maybe about 30% of the time. I haven&apos;t had this problem since the 1.4 prerelease, but maybe I&apos;ve just been lucky.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10102">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="20516">MC-7708</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="21004">MC-8134</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="21008">MC-8137</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="22258">MC-8912</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="22436">MC-9019</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="23447">MC-9711</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="23559">MC-9812</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="23944">MC-10091</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="24468">MC-10509</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="24684">MC-10713</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25171">MC-11079</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27563">MC-12701</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="28046">MC-13111</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="28425">MC-13350</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="169646">MC-116805</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="219820">MC-140007</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="220792">MC-140588</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="220897">MC-140669</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="222375">MC-141375</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="11910">MC-638</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="15268">MC-3284</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="15984">MC-3812</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="17427">MC-4875</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="17579">MC-5019</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="17770">MC-5196</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10103">
                    <name>Relates</name>
                                                                <inwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="20583">MC-7771</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="15241">MC-3259</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                            <attachment id="64589" name="14w21b World(MC-711 Redstone Bug Test.zip) after tp.png" size="813118" author="marcono1234" created="Sun, 1 Jun 2014 16:40:21 +0200"/>
                            <attachment id="11036" name="2012-10-26_06.10.04.png" size="686144" author="npomroy" created="Fri, 26 Oct 2012 10:41:48 +0200"/>
                            <attachment id="11223" name="2012-10-28_03.49.28.png" size="199597" author="npomroy" created="Sun, 28 Oct 2012 07:35:07 +0100"/>
                            <attachment id="11224" name="2012-10-28_03.49.48.png" size="129617" author="npomroy" created="Sun, 28 Oct 2012 07:35:07 +0100"/>
                            <attachment id="88135" name="2015-01-30_22.01.20.png" size="76852" author="TheTamedWolf" created="Sat, 31 Jan 2015 04:18:51 +0100"/>
                            <attachment id="88136" name="2015-01-30_22.01.25.png" size="83418" author="TheTamedWolf" created="Sat, 31 Jan 2015 04:18:51 +0100"/>
                            <attachment id="88137" name="2015-01-30_22.01.33.png" size="68901" author="TheTamedWolf" created="Sat, 31 Jan 2015 04:18:51 +0100"/>
                            <attachment id="88138" name="2015-01-30_22.01.39.png" size="104279" author="TheTamedWolf" created="Sat, 31 Jan 2015 04:18:51 +0100"/>
                            <attachment id="88139" name="2015-01-30_22.01.46.png" size="69712" author="TheTamedWolf" created="Sat, 31 Jan 2015 04:18:51 +0100"/>
                            <attachment id="88140" name="2015-01-30_22.02.14.png" size="207558" author="TheTamedWolf" created="Sat, 31 Jan 2015 04:18:51 +0100"/>
                            <attachment id="237505" name="2019-09-18_12.47.35.png" size="738855" author="Schortan" created="Wed, 18 Sep 2019 12:49:53 +0200"/>
                            <attachment id="24335" name="Frozen repeaters.jpg" size="134025" author="shangen010" created="Wed, 13 Mar 2013 16:58:36 +0100"/>
                            <attachment id="27056" name="MC-711 Redstone Bug Test.zip" size="2393177" author="wolfiemario" created="Fri, 12 Apr 2013 21:22:59 +0200"/>
                            <attachment id="23063" name="chunk-middle-problem-01-basic-setup-repeaters.png" size="161773" author="the.modificator" created="Sat, 2 Mar 2013 13:52:31 +0100"/>
                            <attachment id="23064" name="chunk-middle-problem-02-repeaters-behavior.png" size="296736" author="the.modificator" created="Sat, 2 Mar 2013 13:52:31 +0100"/>
                            <attachment id="23065" name="chunk-middle-problem-03-wire-behavior.png" size="343367" author="the.modificator" created="Sat, 2 Mar 2013 13:52:31 +0100"/>
                            <attachment id="23066" name="chunk-middle-problem-04-comparator-behavior.png" size="273624" author="the.modificator" created="Sat, 2 Mar 2013 13:52:31 +0100"/>
                            <attachment id="23067" name="chunk-middle-problem-05-setup-piston-pushing-redstone-blocks.png" size="366706" author="the.modificator" created="Sat, 2 Mar 2013 13:52:31 +0100"/>
                            <attachment id="23068" name="chunk-middle-problem-06-piston-pushing-redstone-blocks-behavior.png" size="275412" author="the.modificator" created="Sat, 2 Mar 2013 13:52:31 +0100"/>
                            <attachment id="25427" name="comparator-stuck.png" size="73707" author="the.modificator" created="Mon, 18 Mar 2013 14:27:19 +0100"/>
                            <attachment id="25426" name="comparator-stuck.zip" size="6181167" author="the.modificator" created="Mon, 18 Mar 2013 14:27:19 +0100"/>
                            <attachment id="15594" name="crash-2012-12-18_20.41.48-client.txt" size="3471" author="sg2000" created="Tue, 18 Dec 2012 20:49:14 +0100"/>
                            <attachment id="19735" name="crash-2013-01-24_22.15.08-client.txt" size="4417" author="kr1alpha" created="Fri, 25 Jan 2013 04:23:23 +0100"/>
                            <attachment id="20505" name="crash-2013-01-31_20.06.55-client.txt" size="10201" author="kr1alpha" created="Fri, 1 Feb 2013 02:12:35 +0100"/>
                            <attachment id="23438" name="long-redstone-wire-bug-world.zip" size="234797" author="the.modificator" created="Mon, 4 Mar 2013 22:05:10 +0100"/>
                            <attachment id="148352" name="stuck-repeater-clock.png" size="190549" author="Schortan" created="Thu, 5 Oct 2017 18:42:36 +0200"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                    <customfield id="customfield_12800" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Area</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="12602"><![CDATA[Platform]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10701" key="com.atlassian.jira.plugin.system.customfieldtypes:datetime">
                        <customfieldname>CHK</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Fri, 24 Oct 2014 18:56:00 +0200</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11901" key="com.atlassian.jira.plugin.system.customfieldtypes:multiselect">
                        <customfieldname>Category</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="11607"><![CDATA[Chunk loading]]></customfieldvalue>
    <customfieldvalue key="11615"><![CDATA[Redstone]]></customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10500" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Confirmation Status</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10303"><![CDATA[Confirmed]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_11700" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_11100" key="com.atlassian.jira.plugin.system.customfieldtypes:float">
                        <customfieldname>Linked</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>25.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_12200" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Mojang Priority</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="11703"><![CDATA[Low]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                            <customfield id="customfield_10900" key="com.atlassian.jira.plugin.system.customfieldtypes:float">
                        <customfieldname>Pinned</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>25.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11600" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i0mp3z:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_12201" key="com.atlassian.jira.plugin.system.customfieldtypes:datetime">
                        <customfieldname>Triaged Time</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Thu, 28 Nov 2019 09:22:53 +0100</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                </customfields>
    </item>
</channel>
</rss>