<!-- 
RSS generated by JIRA (9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13) at Sun Jan 12 12:26:50 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-11193] The order in which powerable blocks (e.g. redstone dust blocks) along a wire are powered or de-powered is not clearly defined and causes a non-deterministic behavior for redstone contraptions</title>
                <link>https://bugs.mojang.com/browse/MC-11193</link>
                <project id="10400" key="MC">Minecraft: Java Edition</project>
                    <description>&lt;p&gt;First of all: This is NOT a duplicate of &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt;. This ticket actually &lt;b&gt;assumes&lt;/b&gt; that the behavior described in &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt; is &lt;b&gt;intended&lt;/b&gt; behavior.&lt;/p&gt;

&lt;p&gt;Second of all: Sorry, for finding another redstone issue just before the planned pre-release of 1.5, Jeb. :-/&lt;/p&gt;

&lt;p&gt; &lt;b&gt;UPDATE:&lt;/b&gt; I also made a video demonstration for the bug here: &lt;a href=&quot;http://www.youtube.com/watch?v=e5hUYLC8Tms&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.youtube.com/watch?v=e5hUYLC8Tms&lt;/a&gt; You don&apos;t have to read all the text anymore.&lt;/p&gt;


&lt;h3&gt;&lt;a name=&quot;Thesetup&quot;&gt;&lt;/a&gt;The setup&lt;/h3&gt;
&lt;p&gt;Build a setup like in screenshots &quot;basic-setup-1.png&quot; and &quot;basic-setup-2.png&quot; or download and extract &lt;span class=&quot;nobr&quot;&gt;&lt;a href=&quot;https://bugs.mojang.com/secure/attachment/121660/121660_MC-11193.zip&quot; title=&quot;MC-11193.zip attached to MC-11193&quot;&gt;MC-11193.zip&lt;sup&gt;&lt;img class=&quot;rendericon&quot; src=&quot;https://bugs.mojang.com/images/icons/link_attachment_7.gif&quot; height=&quot;7&quot; width=&quot;7&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/sup&gt;&lt;/a&gt;&lt;/span&gt; into your worlds folder for a prebuilt version.&lt;/p&gt;

&lt;h3&gt;&lt;a name=&quot;Thebehavior&quot;&gt;&lt;/a&gt;The behavior&lt;/h3&gt;
&lt;h4&gt;&lt;a name=&quot;CaseA&quot;&gt;&lt;/a&gt;Case A&lt;/h4&gt;
&lt;p&gt;Do this:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Break the redstone wire somewhere.&lt;/li&gt;
	&lt;li&gt;Reconnect it and try breaking it again somewhere else.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Expected behavior: The piston should &lt;b&gt;always&lt;/b&gt; retract, independent of the location where the wire was broken.&lt;/p&gt;

&lt;h4&gt;&lt;a name=&quot;CaseB&quot;&gt;&lt;/a&gt;Case B&lt;/h4&gt;
&lt;p&gt;Preparation: First of all, remove the redstone block at the very left. Then:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Put a redstone block onto one of the blue or gold blocks.&lt;/li&gt;
	&lt;li&gt;Remove it again and try placing it on another blue or gold block.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Expected behavior: The piston should &lt;b&gt;always&lt;/b&gt; retract after removing the redstone block, independent of the location of the block.&lt;/p&gt;

&lt;h4&gt;&lt;a name=&quot;Experiencedbehavior%3A&quot;&gt;&lt;/a&gt;Experienced behavior:&lt;/h4&gt;
&lt;p&gt;The retraction of the piston actually depends on two factors:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;From which location in the world was the redstone wire powered? (Or at which location was the wire broken?)&lt;/li&gt;
	&lt;li&gt;Where is the piston located in the world?&lt;/li&gt;
&lt;/ul&gt;


&lt;h3&gt;&lt;a name=&quot;Theproblem%27ssource&quot;&gt;&lt;/a&gt;The problem&apos;s source&lt;/h3&gt;
&lt;p&gt;The order in which redstone dust blocks that are part of a redstone wire are powered/de-powered seems somewhat undefined/random and seems both dependent on the location of the energy source and the location of those dust blocks. To better understand what I mean, do this:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Remove the piston.&lt;/li&gt;
	&lt;li&gt;Put a command block below each of the two wool blocks.&lt;/li&gt;
	&lt;li&gt;Set the command block on the left (as on the screenshot) to &quot;say 1&quot;.&lt;/li&gt;
	&lt;li&gt;Set the other command block to &quot;say 2&quot;.&lt;/li&gt;
	&lt;li&gt;Power the wire from different locations or break the wire at different locations.&lt;/li&gt;
	&lt;li&gt;Notice that the order changes in which the command blocks are fired.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;This undefined powering order results in the following behaviour.&lt;/p&gt;

&lt;p&gt;As described in &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt;, a piston can be powered diagonally from the top but needs a block update to adjust accordingly to the power level then. In the setup of this ticket, the &lt;font color=&quot;darkmagenta&quot;&gt;&lt;b&gt;magenta wool block&lt;/b&gt;&lt;/font&gt; can power the piston diagonally from the top. Additionally, the &lt;font color=&quot;darkgreen&quot;&gt;&lt;b&gt;green wool block&lt;/b&gt;&lt;/font&gt; can power the piston directly from the top.&lt;/p&gt;

&lt;p&gt;When de-powering the wire, you would expect the following to happen:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;The redstone dust block ontop of the &lt;font color=&quot;darkmagenta&quot;&gt;&lt;b&gt;magenta wool block&lt;/b&gt;&lt;/font&gt; de-powers which de-powers the &lt;font color=&quot;darkmagenta&quot;&gt;&lt;b&gt;magenta wool block&lt;/b&gt;&lt;/font&gt; itself. So the diagonal power source gets turned off. However, this does not update the piston &lt;b&gt;yet&lt;/b&gt;.&lt;/li&gt;
	&lt;li&gt;The redstone dust block ontop of the &lt;font color=&quot;darkgreen&quot;&gt;&lt;b&gt;green wool block&lt;/b&gt;&lt;/font&gt; de-powers which de-powers the &lt;font color=&quot;darkgreen&quot;&gt;&lt;b&gt;green wool block&lt;/b&gt;&lt;/font&gt; itself. As the &lt;font color=&quot;darkgreen&quot;&gt;&lt;b&gt;green wool block&lt;/b&gt;&lt;/font&gt; is adjacent to the piston, the piston receives a block update. It then checks if it should still be extended and thereby finds out that it actually should retract.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;In some occurrences this actually is what happens. Everything is good in those situations.&lt;/p&gt;

&lt;p&gt;However, because of the random redstone dust wire powering order it occurs that actually the &lt;font color=&quot;darkgreen&quot;&gt;&lt;b&gt;green wool block&lt;/b&gt;&lt;/font&gt; gets de-powered &lt;b&gt;BEFORE&lt;/b&gt; the &lt;font color=&quot;darkmagenta&quot;&gt;&lt;b&gt;magenta wool block&lt;/b&gt;&lt;/font&gt;. In those situations, the following happens:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;The redstone dust block ontop of the &lt;font color=&quot;darkgreen&quot;&gt;&lt;b&gt;green wool block&lt;/b&gt;&lt;/font&gt; de-powers which de-powers the &lt;font color=&quot;darkgreen&quot;&gt;&lt;b&gt;green wool block&lt;/b&gt;&lt;/font&gt; itself. This provides a block update to the piston. The piston finds out that it is still powered diagonally (by the &lt;font color=&quot;darkmagenta&quot;&gt;&lt;b&gt;magenta wool block&lt;/b&gt;&lt;/font&gt; which is - at this very moment - still powered). For this reason it does not retract.&lt;/li&gt;
	&lt;li&gt;The redstone dust block ontop of the &lt;font color=&quot;darkmagenta&quot;&gt;&lt;b&gt;magenta wool block&lt;/b&gt;&lt;/font&gt; de-powers which de-powers the &lt;font color=&quot;darkmagenta&quot;&gt;&lt;b&gt;magenta wool block&lt;/b&gt;&lt;/font&gt; itself. Since the wool block is not directly adjacent to the piston, the piston does NOT receive another block update.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;In this situation, the piston simply gets stuck.&lt;/p&gt;


&lt;h3&gt;&lt;a name=&quot;Conclusion&quot;&gt;&lt;/a&gt;Conclusion&lt;/h3&gt;
&lt;p&gt;I always understood Mincraft in a way that every redstone contraption should be deterministic and independent of its location in the world, i.e. you should be able to build something somewhere and if you build the same thing somewhere else it should behave exactly the same. (Deterministic of course still allows bugs like &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt; - even though this is a somewhat unexpected behavior, it is predictable and well-understood. &lt;em&gt;Apart from that I still consider &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt; a bug... but that&apos;s just my personal stance and does not have anything to do with this ticket.&lt;/em&gt;)&lt;/p&gt;

&lt;p&gt;However, as described, the powering order of redstone dust blocks in wires is dependent on the location of those redstone blocks in the world. This results in a somewhat undeterministic behavior: If you build the very same redstone contraption anywhere else in the world, it would work differently - just because of a different wire powering order you encounter there.&lt;/p&gt;

&lt;p&gt;To sum everything up: This ticket describes the need for a well-defined wire powering order to make redstone contraptions deterministic again (or at least &quot;more&quot; deterministic &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; ). IMO, the best resolution would be to simply &quot;follow&quot; the wire and update the power level step-by-step &quot;on the way&quot;. This would also reflect real-world power currents best in this case. (Or to put it differently: You would also most likely expect this to happen based upon your real-world experience with power currents.)&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;Solution provided by &lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=panda4994&quot; class=&quot;user-hover&quot; rel=&quot;panda4994&quot;&gt;panda4994&lt;/a&gt; can be found &lt;a href=&quot;https://bugs.mojang.com/browse/MC-11193?focusedCommentId=320079&amp;amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-320079&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt;.&lt;/p&gt;</description>
                <environment></environment>
        <key id="25303">MC-11193</key>
            <summary>The order in which powerable blocks (e.g. redstone dust blocks) along a wire are powered or de-powered is not clearly defined and causes a non-deterministic behavior for redstone contraptions</summary>
                <type id="1" iconUrl="https://bugs.mojang.com/secure/viewavatar?size=xsmall&amp;avatarId=18903&amp;avatarType=issuetype">Bug</type>
                                    <status id="1" iconUrl="https://bugs.mojang.com/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="the.modificator">The.Modificator</reporter>
                        <labels>
                            <label>experimental_redstone_fixed</label>
                            <label>redstone</label>
                            <label>redstone_wire</label>
                    </labels>
                <created>Thu, 7 Mar 2013 02:24:57 +0100</created>
                <updated>Fri, 25 Oct 2024 09:28:35 +0200</updated>
                                            <version>Snapshot 13w10b</version>
                    <version>Minecraft 1.5</version>
                    <version>Snapshot 13w11a</version>
                    <version>Minecraft 1.5.1</version>
                    <version>Snapshot 13w16a</version>
                    <version>Minecraft 1.5.2</version>
                    <version>Snapshot 13w18c</version>
                    <version>Snapshot 13w19a</version>
                    <version>Snapshot 13w21a</version>
                    <version>Minecraft 1.6.1</version>
                    <version>Minecraft 1.6.2</version>
                    <version>Minecraft 1.6.4</version>
                    <version>Minecraft 13w36a</version>
                    <version>Minecraft 13w36b</version>
                    <version>Minecraft 13w42b</version>
                    <version>Minecraft 13w43a</version>
                    <version>Minecraft 1.7</version>
                    <version>Minecraft 1.7.1</version>
                    <version>Minecraft 1.7.2</version>
                    <version>Minecraft 1.7.4</version>
                    <version>Minecraft 14w04b</version>
                    <version>Minecraft 14w05b</version>
                    <version>Minecraft 14w06a</version>
                    <version>Minecraft 14w06b</version>
                    <version>Minecraft 1.7.5</version>
                    <version>Minecraft 1.7.9</version>
                    <version>Minecraft 14w20a</version>
                    <version>Minecraft 14w20b</version>
                    <version>Minecraft 14w21a</version>
                    <version>Minecraft 14w21b</version>
                    <version>Minecraft 14w34d</version>
                    <version>Minecraft 1.8-pre3</version>
                    <version>Minecraft 1.8</version>
                    <version>Minecraft 1.8.1-pre3</version>
                    <version>Minecraft 1.8.3</version>
                    <version>Minecraft 1.8.4</version>
                    <version>Minecraft 1.8.7</version>
                    <version>Minecraft 15w33c</version>
                    <version>Minecraft 1.8.9</version>
                    <version>Minecraft 16w03a</version>
                    <version>Minecraft 1.9</version>
                    <version>Minecraft 1.9.1 Pre-Release 1</version>
                    <version>Minecraft 1.9.1 Pre-Release 2</version>
                    <version>Minecraft 1.9.1 Pre-Release 3</version>
                    <version>Minecraft 1.9.1</version>
                    <version>Minecraft 1.9.2</version>
                    <version>Minecraft 16w14a</version>
                    <version>Minecraft 16w15b</version>
                    <version>Minecraft 1.9.3 Pre-Release 2</version>
                    <version>Minecraft 1.9.4</version>
                    <version>Minecraft 16w21b</version>
                    <version>Minecraft 1.10.2</version>
                    <version>Minecraft 16w32b</version>
                    <version>Minecraft 16w33a</version>
                    <version>Minecraft 16w42a</version>
                    <version>Minecraft 16w43a</version>
                    <version>Minecraft 1.11</version>
                    <version>Minecraft 1.11.2</version>
                    <version>Minecraft 17w06a</version>
                    <version>Minecraft 17w13b</version>
                    <version>Minecraft 1.12 Pre-Release 6</version>
                    <version>Minecraft 1.12</version>
                    <version>Minecraft 1.12.1 Pre-Release 1</version>
                    <version>Minecraft 1.12.1</version>
                    <version>Minecraft 1.12.2 Pre-Release 1</version>
                    <version>Minecraft 1.12.2</version>
                    <version>Minecraft 18w03b</version>
                    <version>Minecraft 18w07c</version>
                    <version>Minecraft 18w16a</version>
                    <version>Minecraft 18w21b</version>
                    <version>Minecraft 1.13-pre2</version>
                    <version>Minecraft 1.13-pre3</version>
                    <version>Minecraft 1.13-pre4</version>
                    <version>Minecraft 1.13-pre5</version>
                    <version>Minecraft 1.13-pre8</version>
                    <version>Minecraft 1.13</version>
                    <version>Minecraft 18w30b</version>
                    <version>Minecraft 18w31a</version>
                    <version>Minecraft 18w32a</version>
                    <version>Minecraft 1.13.1</version>
                    <version>Minecraft 1.13.2</version>
                    <version>Minecraft 18w45a</version>
                    <version>Minecraft 19w07a</version>
                    <version>Minecraft 1.14.2</version>
                    <version>Minecraft 1.14.3</version>
                    <version>1.14.4</version>
                    <version>19w37a</version>
                    <version>19w46b</version>
                    <version>1.15 Pre-release 1</version>
                    <version>1.15 Pre-release 4</version>
                    <version>1.15.2</version>
                    <version>20w06a</version>
                    <version>20w13b</version>
                    <version>20w18a</version>
                    <version>20w22a</version>
                    <version>1.16 Pre-release 5</version>
                    <version>1.16.1</version>
                    <version>1.16.3</version>
                    <version>20w49a</version>
                    <version>20w51a</version>
                    <version>21w03a</version>
                    <version>1.16.5</version>
                    <version>1.17</version>
                    <version>1.17.1</version>
                    <version>21w39a</version>
                    <version>21w43a</version>
                    <version>1.18.1</version>
                    <version>1.18.2</version>
                    <version>1.19</version>
                    <version>1.19.1</version>
                    <version>1.19.2</version>
                    <version>1.19.3</version>
                    <version>23w03a</version>
                    <version>1.19.4 Release Candidate 3</version>
                    <version>1.19.4</version>
                    <version>23w14a</version>
                    <version>1.20</version>
                    <version>1.20.1</version>
                    <version>23w42a</version>
                    <version>1.21</version>
                    <version>1.21.1</version>
                    <version>24w40a</version>
                    <version>1.21.3</version>
                                                                        <votes>366</votes>
                                    <watches>134</watches>
                                                                            <comments>
                            <comment id="1349670" author="violine1101" created="Tue, 20 Aug 2024 23:40:07 +0200"  >&lt;p&gt;From my understanding (correct me if I&apos;m wrong), it is fixed in the redstone experiment since redstone wire has been changed to either be deterministic or random (in edge cases). I&apos;ve added the label &quot;experimental_redstone_fixed&quot; for us to track these kinds of bug reports until the experiment is merged into the main game.&lt;/p&gt;</comment>
                            <comment id="1347008" author="neko" created="Thu, 15 Aug 2024 20:39:32 +0200"  >&lt;p&gt;Is this still an issue in 24w33a?&lt;/p&gt;</comment>
                            <comment id="1334698" author="JIRAUSER491703" created="Wed, 26 Jun 2024 07:41:53 +0200"  >&lt;p&gt;Affects 1.21&lt;/p&gt;</comment>
                            <comment id="1286188" author="ic22487" created="Fri, 20 Oct 2023 03:09:20 +0200"  >&lt;p&gt;Can confirm in 23w42a&lt;/p&gt;</comment>
                            <comment id="1233200" author="JIRAUSER741834" created="Mon, 23 Jan 2023 14:44:47 +0100"  >&lt;p&gt;Can confirm in 23w03a.&lt;/p&gt;</comment>
                            <comment id="1140741" author="JIRAUSER663810" created="Fri, 11 Feb 2022 02:21:33 +0100"  >&lt;p&gt;can confirm in 1.18.1&lt;/p&gt;</comment>
                            <comment id="1138479" author="farogaming" created="Sun, 30 Jan 2022 16:38:15 +0100"  >&lt;p&gt;The rails thing is &lt;a href=&quot;https://bugs.mojang.com/browse/MC-957&quot; title=&quot;Powered rails do not update when additional power sources are added or removed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-957&quot;&gt;MC-957&lt;/a&gt; and happens because they don&apos;t have the power states that redstone has.&lt;/p&gt;</comment>
                            <comment id="1138434" author="nopse" created="Sun, 30 Jan 2022 10:22:51 +0100"  >&lt;p&gt;Thanks for the nice explanation, this helped me to find a workaround for the bug. If you want to expand/retract a couple of pistons connected to a power line, don&apos;t connect them directly to the power line, put a repeater between each piston and the power line, then they reliably retract, if you switch the power line off. But I have to say, this feels stupid, waste of material and space! Either they should skip the BUD &quot;feature&quot;, or add some synchronization, but together these two are a fatal combination! I noticed, that sometimes powered rails stay powered on too, when you switch off the power, is this related to this ? &#160;&lt;/p&gt;</comment>
                            <comment id="1048667" author="JIRAUSER673019" created="Sun, 1 Aug 2021 01:30:16 +0200"  >&lt;p&gt;Mojang its been 8 years, i feel like the priority of this notorious bug should be higher than &quot;low&quot;, some redstone contraptions just do not work because of location, and thats just bad.&lt;/p&gt;



&lt;p&gt;also its confirmed for 1.18 experimental snapshot, but idk if its important since its experimental and all&lt;/p&gt;</comment>
                            <comment id="1032558" author="JIRAUSER648933" created="Fri, 9 Jul 2021 02:08:48 +0200"  >&lt;p&gt;Can confirm in 1.17.1.&lt;/p&gt;</comment>
                            <comment id="1016128" author="JIRAUSER648933" created="Tue, 15 Jun 2021 19:03:09 +0200"  >&lt;p&gt;Can confirm in 1.17.&lt;/p&gt;</comment>
                            <comment id="929614" author="awesoman3000" created="Tue, 23 Feb 2021 16:36:32 +0100"  >&lt;p&gt;Relates to &lt;a href=&quot;https://bugs.mojang.com/browse/MC-11613&quot; title=&quot;Directional bug with one tick pulsers&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-11613&quot;&gt;MC-11613&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="900233" author="JIRAUSER568020" created="Wed, 20 Jan 2021 18:15:29 +0100"  >&lt;p&gt;Still an issue in snapshot &lt;b&gt;21w03a&lt;/b&gt;&lt;/p&gt;</comment>
                            <comment id="867661" author="JIRAUSER568020" created="Sun, 20 Dec 2020 12:44:38 +0100"  >&lt;p&gt;Still an issue in snapshot &lt;b&gt;20W51A&lt;/b&gt;&lt;/p&gt;</comment>
                            <comment id="862813" author="JIRAUSER568020" created="Mon, 14 Dec 2020 11:10:06 +0100"  >&lt;p&gt;confirmed for the snapshot &lt;b&gt;20w49a&lt;/b&gt;&lt;/p&gt;</comment>
                            <comment id="731068" author="JIRAUSER506209" created="Mon, 15 Jun 2020 15:55:37 +0200"  >&lt;p&gt;Hi, I was considering submitting a bug report for some really weird behavior breaking a dispenser hopper T flip-flop, but found this issue and wanted to check that it isn&apos;t caused by the same bug.&lt;/p&gt;

&lt;p&gt;I think this simplified setup using pistons demonstrates the problem clearly:&lt;/p&gt;

&lt;p&gt;I have the exact same configuration for both sides, and am expecting the same result (that the top piston fires &quot;first&quot; preventing it from being moved).&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/attachment/309354/309354_image-2020-06-15-14-48-29-121.png&quot; height=&quot;168&quot; width=&quot;299&quot; style=&quot;border: 0px solid black&quot; /&gt;&lt;/span&gt;&lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/attachment/309355/309355_image-2020-06-15-14-48-46-781.png&quot; height=&quot;168&quot; width=&quot;299&quot; style=&quot;border: 0px solid black&quot; /&gt;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;However this doesn&apos;t occur for the pistons on the right (shown above), but does occur for the pistons on the left (shown below)&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/attachment/309356/309356_image-2020-06-15-14-51-55-708.png&quot; height=&quot;168&quot; width=&quot;299&quot; style=&quot;border: 0px solid black&quot; /&gt;&lt;/span&gt;&lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/attachment/309358/309358_image-2020-06-15-14-52-17-953.png&quot; height=&quot;168&quot; width=&quot;299&quot; style=&quot;border: 0px solid black&quot; /&gt;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;This does appear to be location dependent (although not in any pattern I can figure out) and replacing the pistons for droppers results in the same issues.&lt;/p&gt;</comment>
                            <comment id="693259" author="carretero mart&#237;nez" created="Sat, 9 May 2020 17:52:59 +0200"  >&lt;p&gt;May I suggest that, since this is a very followed issue, And a lot of people is watching the issue, perhaps further discussion should be moved onto the sub-reddit thread&#160;&lt;/p&gt;</comment>
                            <comment id="692427" author="bugi74" created="Fri, 8 May 2020 17:08:59 +0200"  >&lt;p&gt;&quot;without limits the logic will be correct (door will open/close... eventually) but its desired function will not be correct&quot;&lt;br/&gt;
 &lt;cite&gt;So you mean after the limit is reached, block updates will be moved to the next tick? That is less bad in some simple cases, but those simple cases already aren&apos;t a problem for performance anyway and the more complicated cases would completely break with it.&lt;/cite&gt;&lt;br/&gt;
 &lt;cite&gt;BTW, this report is not about performance.&lt;/cite&gt;&lt;/p&gt;

&lt;p&gt;TLDR: the main point was the separation of &quot;current&quot; output state and the &quot;next&quot; output state. The tricky part is when that &quot;next&quot; gets applied to be the &quot;current&quot; (and is something I won&apos;t dare to emphasize one choice over another).&lt;/p&gt;

&lt;p&gt;I was considering the situation where there are both simple mechanisms (say, that door) and heavy systems in the same area. In such a situation it does get messy no matter what, though.&#160; Of course a few simple things alone will work well in (almost) all solutions, even with the current little bit borked solution.&lt;/p&gt;

&lt;p&gt;The idea with time-limit is to continue processing changes from outputs to inputs in the next cycle of calculations, but any already accumulated output changes would be applied first at the next cycle.&#160;If the output changes are not applied like that (after time-limit), the behavior turns back into the same as without time-limit, just perhaps causing slightly less effect on rest of the game (physics, reacting to user-input, etc.), just like with any other properly designed throttling mechanism for heavy load handling.&lt;/p&gt;

&lt;p&gt;The time-limit idea is to simply stop processing further redstone calculations during that cycle (whether that is a tick or some other time period), flip the outputs (where necessary), and on the next cycle continue either from &quot;begin&quot; or where the processing was left at (another choice to make, with different pros and cons). This way at least something happens somewhat smoothly under heavy load, though it can not be said what exactly will be smooth and what will not. (I would have ideas even for that last &quot;problem&quot;, but that goes waaayyy in the land of feature request.)&lt;/p&gt;

&lt;p&gt;Time-limit is of course not the only way to manage overload situation.&lt;/p&gt;

&lt;p&gt;I know this report isn&apos;t about performance, that is why I don&apos;t even suggest any choice over another. I mentioned the time-limit so as to let everyone know about the possible issues remaining even with my suggestion towards fixing this issue. (So that nobody can outright deny the approach by saying that I forgot that it will break under heavy load (as if the current one wouldn&apos;t), etc.)&#160; Also, when it comes to time-limit, the logic works a bit differently when using the next state buffer vs. the way where every change is applied to world immediately. E.g. in the easier/current way (no next output state buffer), a time-limit wouldn&apos;t really make a difference in the outcome.&lt;/p&gt;</comment>
                            <comment id="692367" author="farogaming" created="Fri, 8 May 2020 15:55:19 +0200"  >&lt;p&gt;&lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=Markku&quot; class=&quot;user-hover&quot; rel=&quot;Markku&quot;&gt;Markku&lt;/a&gt;&lt;br/&gt;
&quot;breaking BUDs is something people (including Mojang dev(s), IIRC) have used to justify not fixing a clear bug&quot;&lt;br/&gt;
Well, that&apos;s bad then. Was that before observers existed or after?&lt;br/&gt;
Also, Mojang sometimes changes their mind. &lt;a href=&quot;https://bugs.mojang.com/browse/MC-9405&quot; title=&quot;Top piece of staircase redstone dust doesn&amp;#39;t power blocks on the same height in the direction it is powered from unless only connected to something on the other side&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-9405&quot;&gt;&lt;del&gt;MC-9405&lt;/del&gt;&lt;/a&gt; was &quot;won&apos;t fix&quot; at first and then it was fixed (that snapshot even got released while the report was still marked as resolved). And whether &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt; is a bug or a feature depends on which dev you ask, on what day, at what weather seemingly, &#8230;&lt;/p&gt;

&lt;p&gt;&quot;I gave up years ago on trying to use proper reasoning and good programming habits/rules when it comes to Minecraft development.&quot;&lt;br/&gt;
You shouldn&apos;t. Just because many people ignore best practises doesn&apos;t mean they should be ignored by everyone. It is already the case in most software projects that most best practises are ignored by most people, but every bit helps.&lt;br/&gt;
The thing is, BUDs (without observers) are based on bringing something to an &quot;invalid state&quot; and then detecting when the game finally notices and auto-fixes it. Sounds like the prime example of &quot;bug-using&quot; to me.&lt;/p&gt;

&lt;p&gt;&quot;without limits the logic will be correct (door will open/close... eventually) but its desired function will not be correct&quot;&lt;br/&gt;
So you mean after the limit is reached, block updates will be moved to the next tick? That is less bad in some simple cases, but those simple cases already aren&apos;t a problem for performance anyway and the more complicated cases would completely break with it.&lt;br/&gt;
BTW, this report is not about performance.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=Precurse&quot; class=&quot;user-hover&quot; rel=&quot;Precurse&quot;&gt;Precurse&lt;/a&gt; You can tag people with &lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;[~name]&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;, but that only makes it link to the profile and it updates the displayed name when the person&apos;s name changes, it changes nothing about notifications or similar.&lt;br/&gt;
Also, the &quot;preview&quot; button is sadly gone, but you can use Ctrl+A Ctrl+C to copy your text, click the &quot;visual&quot; button to see how it looks and then switch back to &quot;text&quot; and restore everything that the visual mode messed up (which it sadly often does) with Ctrl+A Ctrl+V. Your many edits causes 105 times as many mails to be sent, that&apos;s multiple thousands in total from this conversation today.&lt;/p&gt;</comment>
                            <comment id="692158" author="bugi74" created="Fri, 8 May 2020 12:31:26 +0200"  >&lt;p&gt;&lt;cite&gt;&quot;It may or may not cause issues with BUDs&quot; All BUDs except observers are fundamentally based on bugs, so that&apos;s not a problem.&lt;/cite&gt;&lt;/p&gt;

&lt;p&gt;Except that breaking BUDs is something people (including Mojang dev(s), IIRC) have used to justify not fixing a clear bug, so it can be a problem (for one or the other group of people). I&apos;ve even given suggestions that would result in having both BUDs and properly working redstone logic.. to no effect. I gave up years ago on trying to use proper reasoning and good programming habits/rules when it comes to Minecraft development.&lt;/p&gt;

&lt;p&gt;&lt;cite&gt;A time limit after which every remaining update is skipped is definitely a bad idea, because it leads to infinite possible problems that cannot even be reproduced properly and are also unfixable.&lt;/cite&gt;&lt;/p&gt;

&lt;p&gt;IIRC, those maaany years ago when I last went in the code, there was a limit on how many updates could be queued, after which either oldest or the latest were simply dropped (not processed), which essentially leads to similar behavior as a time-limit. I.e. incorrect operation, in a random way, not always reproducible.&#160; At least my largest redstone things at the time definitely behaved badly when everything was turned on at once.&#160; So, I&apos;m not sure if that is (or was) really so bad idea (at least in Mojang&apos;s view).&lt;/p&gt;

&lt;p&gt;In a more practical way, having a time-limit (or another process limiting method) may allow something to work well and fast at least sometimes (say, a simple automated door, keeping you safe from the mobs), while without limits the logic will be correct (door will open/close.... .... ... eventually) but its desired function will not be &quot;correct&quot; (to keep you safe).&#160; I.e. both ways have their pros and cons.&lt;/p&gt;</comment>
                            <comment id="692145" author="farogaming" created="Fri, 8 May 2020 12:13:57 +0200"  >&lt;p&gt;The delays for everything were a joke (as indicated by &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;). If every component had delays, it would make everything extremely slow and not even fix this bug.&lt;/p&gt;

&lt;p&gt;&quot;It may or may not cause issues with BUDs&quot; All BUDs except observers are fundamentally based on bugs, so that&apos;s not a problem.&lt;/p&gt;

&lt;p&gt;A time limit after which every remaining update is skipped is definitely a bad idea, because it leads to infinite possible problems that cannot even be reproduced properly and are also unfixable.&lt;/p&gt;

&lt;p&gt;Do you have an example of a contraption that is locational and would be computationally extremely inefficient to make non-locational? I can&apos;t imagine any reason why that would be the case.&lt;/p&gt;

&lt;p&gt;BTW, it&apos;s &quot;tick&quot;, not &quot;tic&quot;.&lt;/p&gt;</comment>
                            <comment id="692112" author="JIRAUSER481006" created="Fri, 8 May 2020 11:32:52 +0200"  >&lt;p&gt;Response to the comments from @(Fabian R&#246;ling)&#160;and @(Pegasus Epsilon)&#160;&lt;/p&gt;

&lt;p&gt;1) &#160;To clarify&#160;I don&#8217;t mean that the update order is impossible to make in a predictable intuitive way, just that because of how computers work (sequential) it would be incredibly difficult without drastically increasing the amount of calculations required. At that point the cost can quickly outweigh the gain. So not impossible, just impractical.&lt;/p&gt;

&lt;p&gt;2) As I understand the game it should be impossible to create loops in the last step. The only two blocks that can change the state of the world in such a way that I can see are dispensers (can place certain blocks, blocking redstone wire or getting strongly powered) and pistons (moving a powered block, moving a block blocking redstone wire over an ledge). The dispenser uses 2 redstone ticks to activate and can therefore not be looped this tick. The piston starts moving the same tick, and moving blocks loses their ability block or power redstone, and therefore instantly cause a change. As I understand it the blocks would only return to solid blocks in a future tick and can therefore not be looped. So, while long chains are possible, loops should be impossible. Exactly where in the process the dispensers place the block or the moved block turns solid should also be considered.&lt;/p&gt;

&lt;p&gt;3) I thought 0-tick pulses was a quirk (like quasi-connectivity) rather than a bug, and specifically included the last step to conserve it. Simply removing that step should remove all the cases of 0-ticks that I can think of, because affected wire/components only would &#8216;see&#8217; that something had changed the next tick.&lt;/p&gt;

&lt;p&gt;I updated the main text to clarify.&lt;/p&gt;

&lt;p&gt;Edit: Some grammar fixes (although i still think redstone has its tics as well &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;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="692094" author="bugi74" created="Fri, 8 May 2020 11:06:07 +0200"  >&lt;p&gt;Not all redstone components/mechanisms need to have a delay of game ticks (or similar). Delay is essentially just one way to achieve input-to-output separation and thus (mostly) correct logic.&lt;/p&gt;

&lt;p&gt;Another way to do it is what had been proposed ages ago, which is to separate current and next output states. As long as any (sub-tick) calculations are still going (and optionally some time-limit has not been exceeded), output states would not be changed (except if a component is defined to be instant, like redstone wire, but such component needs to have logic/behavior that is safe for the instant processing, not leading to oscillation). Once everything is done and stable, flip all outputs (without starting to process/propagate updates yet) in one go. Then repeat in calculating how the new state changes things (those updates propagating to inputs), while holding outputs fixed. This way it should also at least reduce, if not eliminate any position/orientation dependency, except in cases like the symmetric pistons etc. where the nature of the situation is such that it really should be more or less random (equal rules fighting each other..).&lt;/p&gt;

&lt;p&gt;The above description is actually effectively also a delay, but it is a dynamic one; it only lasts as short or long as the propagation needs, not some specific quantity of &quot;ticks&quot;... except if specifically delayed to a desired time resolution. E.g. by starting the round of processing, or by doing the output flip part, only once per tick, then one gets the ideal version of current behavior; things would change once per tick (or sub-tick or whatever proper unit is/was for redstone), but would do so without (time/order/position/orientation related) quirks.&#160; It may or may not cause issues with BUDs, though, depending on which kind of rule/mechanism was making such BUD to work as it does.&lt;/p&gt;

&lt;p&gt;The &quot;optional time-limit&quot; I mentioned matters. If no time-limit, all redstone operation slows down when there is too much stuff going, but its logic works correctly (except for timing vs. other systems, like physics of flying/dropping items). With a processing time-limit, redstone works as fast as usual even under load, but at heavy load something may need to be left unprocessed before the outputs are flipped, which leads to incorrect operation. Which way is better depends on the particular system/needs.&#160; I am not suggesting such option should be added, or which way is better in general, I only mentioned it as it affects the result and it can not be left undecided.&lt;/p&gt;</comment>
                            <comment id="692056" author="farogaming" created="Fri, 8 May 2020 10:06:01 +0200"  >&lt;p&gt;Replies to &lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=Precurse&quot; class=&quot;user-hover&quot; rel=&quot;Precurse&quot;&gt;Precurse&lt;/a&gt;:&lt;br/&gt;
1. &quot;stuff happens in a different order depending on coordinates&quot; is not an unsolvable problem. Hard, but not unsolvable. That things happen differently depending on rotation is unsolvable in some situations, for example if you power two pistons facing each other with only one block gap in the middle at the same time, then rotating that contraption by 180&#176; would of course change the result, because you arrive at the same situation, just with the two pistons having switched places (let&apos;s say they have something to keep them apart, like sticky or not). The only thing you could do against this would be the MCBE strategy: Randomness. I don&apos;t personally think that this is a good solution, but there are different opinions on this. See also this video by Panda: &lt;a href=&quot;https://www.youtube.com/watch?v=aRr3NpmQiCg&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://www.youtube.com/watch?v=aRr3NpmQiCg&lt;/a&gt;&lt;br/&gt;
2. Note that 0-ticks are considered a bug: &lt;a href=&quot;https://bugs.mojang.com/browse/MC-8328&quot; title=&quot;Powered mechanisms react when receiving a 0 tick redstone signal (existence of micro-pulses in general / inconsistent block update &amp;#39;algorithm&amp;#39;)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-8328&quot;&gt;MC-8328&lt;/a&gt; But it might be impossible to fix all cases of them.&lt;/p&gt;

&lt;p&gt;Reply to &lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=Pegasus+Epsilon&quot; class=&quot;user-hover&quot; rel=&quot;Pegasus Epsilon&quot;&gt;Pegasus Epsilon&lt;/a&gt;: At least currently you would probably get a StackOverflow, which is already sometimes used for update suppression, but that&apos;s a bug as well. The solution is obviously to let every redstone component and physical mechanism have a delay. &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="691666" author="pegasus epsilon" created="Fri, 8 May 2020 00:52:04 +0200"  >&lt;p&gt;The good:&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;The BUD problem is a valid statement, BUDs should be deterministic regardless of coordinate, and fixing that &lt;b&gt;first&lt;/b&gt;, will greatly simplify the rest of this problem.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;The bad:&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;The idea that a circuit cannot be emulated properly regardless of coordinates is provably false. There are numerous circuit emulators out there that work just fine regardless of where you drag the components around in their UI. A &quot;computer&quot; incapable of deterministic operation is a worthless device.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;I think we do need (at least) three separate passes on all redstone components in a circuit to do it properly, but the idea that it can&apos;t be done is absurd.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;&#160;The funny:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;If something changed the same tic*k* (e.g. piston moving powered blocks) repeat.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;$10 says I can use this piece of your proposed patch alone to send your server into a CPU-hogging infinite loop and never tick again.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="691252" author="JIRAUSER481006" created="Thu, 7 May 2020 15:24:22 +0200"  >&lt;p&gt;I personally feel that you can divide this problem into two different categories. One is the more &#8220;literal&#8221; one, in that stuff happens in a different order depending on coordinates. The consequences of this can be seen in command blocks triggering in different orders or that a dropper chain sends an item a different distance when all power on. This is a natural result of the sequential nature of computers and will never quite go away. The focus should therefor be to fix the second category, although my suggestion for a solution would make even the first category more manageable.&lt;/p&gt;

&lt;p&gt;Edit: To clarify&#160;I don&#8217;t mean that the update order is impossible to make in a predictable intuitive way, just that because of how computers work (sequential) it would be difficult without drastically increasing the amount of calculations required. At that point the cost can quickly outweigh the gain. So not impossible, just impractical.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;The second category consists of the situation where the update order causes unpredictable inconsistencies in redstone. Quasi-connectivity is the origin of a large part of these and can cause pistons or droppers/dispensers be BUD-ed (typically on falling edge) for seemingly no reason. This should be a priority to fix, as they cause confusion for the player and can often break contraptions. I do believe some of the inconsistencies with how repeaters and comparators handle fast clocks (some cases signal propagation, some cases off and some cases on) could also be put in this category (not sure).&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;My suggestion to fix this is to create a better-defined order of (redstone) updates. As far as I can logically think the order should be something like this&lt;/p&gt;

&lt;p&gt;1) The empowering components. Redstone torches, comparators and repeaters that are tagged for change does that. Affected blocks/components are queued for change.&lt;/p&gt;

&lt;p&gt;2) The blocks that becomes strongly powered or looses said state gets updated. Affected blocks/components are tagged for change. If a component like a dropper gets powered at this stage, it only acts like a solid block at this stage and is queued for change as appropriate.&lt;/p&gt;

&lt;p&gt;3) Redstone wire gets handled. Queue appropriate components for change.&lt;/p&gt;

&lt;p&gt;4) Weakly powered blocks updates.&lt;/p&gt;

&lt;p&gt;5) All components that cause block updates (that have not already been checked) should be noted, and all components that are updated should be queued for execution (but not actually done yet). Do this recursively so that everything is queued for execution.&lt;/p&gt;

&lt;p&gt;6) Execute the behaviour of all the components queued for action. As it is only at/after this stage pistons and dispensers can influence the world, no consequences of those action should have been handled.&lt;/p&gt;

&lt;p&gt;7) If the world has been influenced (pistons moving a powered block etc), repeat the steps. They should keep repeating until they are done, as things like instant (falling edge piston) signals requires multiple loops. The game should already be free of potential closed loops.&lt;/p&gt;

&lt;p&gt;Edit: To clarify the only two blocks that can change the state of the world in such a way that I can see are dispensers (can place certain blocks, blocking redstone wire or getting strongly powered) and pistons (moving a powered block, moving a block blocking redstone wire over an ledge). The dispenser uses 2 redstone ticks to activate and can therefore not be looped this tick. The piston starts moving the same tick, and moving blocks loses their ability block or power redstone, and therefore instantly cause a change. As I understand it the blocks would only return to solid blocks in a future tick and can therefore not be looped. So, while long chains are possible, loops should be impossible. Exactly where in the process the dispensers place the block or the moved block turns solid should also be considered.&#160;Note that I included this last step to conserve 0-tick behaviour. If it is a bug rather than a quirk (like quasi-connectivity), simply dropping step 7 should remove all 0-tick behaviour I can think of as the change only gets registered the next tick.&lt;/p&gt;

&lt;p&gt;I believe this loop would keep the behaviour more constant (no variable BUDing) while staying mostly the same (for example 0 tick pistons and pulses should still work).&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;In addition, I believe it is sensible to instead of activating all components in the order they where detected, to separate the different components into their own queues (one queue for droppers, one queue for trapdoors, one queue for both piston types). While the update order within each queue is the same as it is now (if only there was components of that type), but create a known hierarchy between the different. For example, fire all droppers before any dispensers fire. The result of this addition would be a much clearer update order, something that partially fixes the first category problem. It would also lower the skill celling for working with these timings benefitting casual(ish) players. Note that the hierarchy and content of the queues is important and should be thoroughly considered. For example, droppers should activate before dispensers as droppers can be used to move an item and using it the same tick. Likewise, both pistons types should be in the same queue to conserve loads of currently vital behaviour. And depending on if pistons are prior to dispensers the behaviour could differ, although if the steps mentioned above are followed using pistons to (de)power components in different loops the order can be accurately manipulated.&lt;/p&gt;

&lt;p&gt;To implement this in the code I imagine &quot;all&quot; you need is to fill different FIFO queues with blocks/wire/components to power. If something powers something handled in a different step, put it in the appropriate queue. A wire on top of a dispenser should queue it in both the &#8216;weakly powered block queue&#8217; to see if something reacts to that, and the &#8216;dispensers to be activated queue&#8217;. Redstone wire powering redstone wire are both on the same step, and don&#8217;t need to be queued. The idea is to have a &#8216;detect all, then execute all&#8217; approach instead of the &#8216;detect execute repeat&#8217; approach it seemingly has now (could be completely wrong there. Don&#8217;t know any Java nor the inner workings of the game).&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;Although some of the more advanced contraption that are orientation dependent probably would break, a more well-defined update order would make it easier and more predictable to redesign most of them. It would remove inconsistencies and make the process more beginner friendly, all while staying mostly the same as now. And lastly it would offer more manipulation of chain of events for advanced players opening new possibilities. So, in total something I think would be worth implementing.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;TL; DR: This problem has a &#8220;everything happens, but in a location dependent order&#8221; part and a &#8220;things can get BUD-ed dependent on location&#8221; part. I personally think the BUD part should be a high priority to fix. My suggestion to do that is to have a component-dependent update order. First things that gives redstone power (repeaters, redstone torch, comparator), then strongly powered blocks, then redstone wire, weakly powered blocks, and lastly activate the components. If something changed the same tick (e.g. piston moving powered blocks) repeat. The different components with behaviour should have a strict order of activation (like all droppers activate before any dispensers do. Order among in a single category can have a similar order as now). &#160;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;I hope this ramble could be of some help or inspiration, and don&#8217;t only make sense in my head.&lt;/p&gt;

&lt;p&gt;Edit: Some grammar fixes (although i still think redstone has its tics as well &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="684934" author="JIRAUSER476151" created="Thu, 30 Apr 2020 16:02:07 +0200"  >&lt;p&gt;This is now happening as for snapshot 20w18a.&lt;/p&gt;

&lt;p&gt;(Didn&apos;t see this ticket when created &lt;a href=&quot;https://bugs.mojang.com/browse/MC-181606&quot; title=&quot;Pistons don&amp;#39;t retract in certain situations 20w18a&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-181606&quot;&gt;&lt;del&gt;MC-181606&lt;/del&gt;&lt;/a&gt; but it seems essentially the same)&lt;/p&gt;</comment>
                            <comment id="606663" author="vktec" created="Fri, 22 Nov 2019 03:28:23 +0100"  >&lt;p&gt;Just to make sure I wasn&apos;t being an idiot, I wrote a mod using my suggested fix. It seems to work fine, but I&apos;ve not done particularly extensive testing. If anyone feels like playing with it, the code is here: &lt;a href=&quot;https://github.com/vktec/wire-order-fix&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/vktec/wire-order-fix&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;A JAR file for 1.14.4 Fabric can be downloaded from here if you don&apos;t feel like compiling it yourself: &lt;a href=&quot;https://github.com/vktec/wire-order-fix/releases/tag/0.1.0&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/vktec/wire-order-fix/releases/tag/0.1.0&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="601482" author="vktec" created="Tue, 12 Nov 2019 23:03:41 +0100"  >&lt;p&gt;I think you may be out of date. updatePowerStrengthImpl is the only place where toUpdate is modified, and performs no recursive calls that I can see. updatePowerStrength clears toUpdate directly after calling updatePowerStrengthImpl which, as you say, makes the set pointless.&lt;/p&gt;

&lt;p&gt;There may be a hidden recursive call I&apos;m missing, however.&lt;/p&gt;</comment>
                            <comment id="601379" author="bugi74" created="Tue, 12 Nov 2019 18:33:59 +0100"  >&lt;p&gt;I haven&apos;t read the relevant code in years, so things could have changed over the time, and/or I could remember wrong... but, trying to read between the lines, it seems that if there have been changes, they haven&apos;t been the kind of that would have been needed. So, what I say may miss the mark, but should still give the idea(s) behind it all.&lt;/p&gt;

&lt;p&gt;The hashset of blocks to be updated can hold more blocks than just the one and its neighbours. (Or at least it should, otherwise it would indeed be pointless.)&#160; Note that while the blocks have class and object, the object (or class) is used as a &quot;representative&quot;, not for individual blocks. (Or at least that was the way it worked back then, IIRC.)&#160; Thus, a field in the object (let alone in the class) is actually shared by all blocks of the same type (or aboutish, depends on the particular code).&lt;/p&gt;

&lt;p&gt;The point of that set is to collect all the to-be-updated blocks/positions into one collection, with no duplicates (it is a &quot;set&quot; after all). The travel through the propagation of redstone effect on a wire can branch and rejoin many times, so each block can be seen multiple times. If not done via a set, there could blocks that get updated multiple times during a tick, and depending on the block type, that could then spread further.&lt;/p&gt;

&lt;p&gt;Also, while I don&apos;t remember whether it was the same set or another, there is a need to check if a particular redstone block has already been handled during the same tick (to avoid infinite loops and for efficiency).&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;The problem in this issue is (partially!) specifically due to the way the set works and is used; the order in which the contents of the set can be gone through is not the same in all cases of an identical circuit (not only as a hashset implementation can validly have randomness in its working, but also due to how the hash-value is calculated for the blocks in this purpose). And due to the way the redstone logic updates are handled, the order in which the changes happen to various blocks during a single tick can lead different end results. Additionally sometimes affected by non-redstone based updates. (The sub-tick quirks have been abused for various purposes over time, too, so.. fix this problem, and break a few circuits.)&lt;/p&gt;

&lt;p&gt;Read Panda&apos;s long comment which notes about LinkedHashSet; it would reduce some of the overall causes, but not all.&lt;/p&gt;

&lt;p&gt;Read my and Panda&apos;s comments through to get a better idea how much is needed to get it done properly. It is not really that difficult, but it is not a small change, either.&lt;/p&gt;</comment>
                            <comment id="601239" author="vktec" created="Tue, 12 Nov 2019 05:02:23 +0100"  >&lt;p&gt;Perhaps I&apos;m misreading the code, but as I see it, updatePowerStrength and updatePowerStrengthImpl could be merged into one method, with toUpdate being a local variable (which would be slightly slower than having it as a field, my point is just that it could be done).&lt;/p&gt;

&lt;p&gt;Since the blocks which get added to toUpdate are the same every time, and none of those will be the same as any other (they&apos;re the redstone wire block and the 4 blocks in each cardinal direction from it), I see no reason to store them in a HashSet at all.&lt;/p&gt;

&lt;p&gt;Again, I may well be reading the code wrong and it&apos;s much more complex than I think.&lt;/p&gt;</comment>
                            <comment id="599703" author="bugi74" created="Fri, 8 Nov 2019 09:35:34 +0100"  >&lt;p&gt;The &quot;update as positions are found&quot; was suggested already by the ticket description, which I sort of debunked in the first comment...&#160; I and Panda have given couple ways to handle it properly. (And hint, there is no &quot;simple&quot; way to solve it properly, although what is and isn&apos;t simple may vary from developer to developer.)&lt;/p&gt;

&lt;p&gt;About showing code here. I haven&apos;t seen any solid official guide in what is and isn&apos;t allowed in that regard, but I&apos;ve shown quite a bit code snippets in here, with no trouble so far. And at least one fix I have shown here has even been used by a developer (with confirmation in the issue&apos;s comment). However, I limited myself to relatively small snippets, at most full medium sized functions.&lt;/p&gt;

&lt;p&gt;Also note that large part of mod development would already break the same EULA rules, so if they want to kill source code snippets here, then for equality good bye mods...&lt;/p&gt;</comment>
                            <comment id="599698" author="farogaming" created="Fri, 8 Nov 2019 08:38:39 +0100"  >&lt;p&gt;Would that decrease performance? I think this collection and later execution of updates is done so that redstone dust doesn&apos;t keep updating itself hundreds of times over whenever you e.g. depower a line from 15 to 0. (It still does that a lot, but less than it would with regular block updates only.)&lt;/p&gt;</comment>
                            <comment id="599663" author="vktec" created="Fri, 8 Nov 2019 03:19:15 +0100"  >&lt;p&gt;One simple method to make redstone wire update in a more predictable manner would simply be to stop using the `toUpdate` field of `net.minecraft.world.level.block.RedStoneWireBlock`: instead of adding the positions to be updated to a set which is later iterated over and then cleared (note that the only uses of `toUpdate` are in `updatePowerStrength` and `updatePowerStrengthImpl`), simply update the positions as they are found - call `Level.updateNeighborsAt` once with the position of the dust, then once per Direction, utilizing the loop in `updatePowerStrengthImpl` that currently adds the positions to the `toUpdate` set.&lt;/p&gt;

&lt;p&gt;I could create a patch showing these changes, but I&apos;m not sure how useful it would be since it&apos;s deobfuscated code, and am also unsure about whether or not it violates the EULA&lt;/p&gt;</comment>
                            <comment id="576318" author="redcmd" created="Wed, 21 Aug 2019 21:43:40 +0200"  >&lt;p&gt;Yes but he is saying that&lt;br/&gt;
NO! java should NOT have random redstone&lt;br/&gt;
It is a terrible idea, directional is much better&lt;br/&gt;
and theres many different things that can be coded to reduce the directionalness&lt;/p&gt;</comment>
                            <comment id="576301" author="theandroidman" created="Wed, 21 Aug 2019 20:11:45 +0200"  >&lt;p&gt;Matt, that video applies to Bedrock Edition. This is a Java Edition bug.&lt;/p&gt;</comment>
                            <comment id="576283" author="matrix1121" created="Wed, 21 Aug 2019 17:49:00 +0200"  >&lt;p&gt;See YouTube video &lt;a href=&quot;https://youtu.be/wVJDz0ca7Ps&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://youtu.be/wVJDz0ca7Ps&lt;/a&gt;. Time stamp at 1:50.&#160;&lt;/p&gt;</comment>
                            <comment id="563895" author="redcmd" created="Mon, 8 Jul 2019 04:27:52 +0200"  >&lt;p&gt;Sven&lt;br/&gt;
The &apos;random&apos; redstone dust update order, does cause the dropper to be budded sometimes but not other times&lt;br/&gt;
Droppers and dispensers can be QC powered like pistons&lt;/p&gt;</comment>
                            <comment id="563438" author="2called-chaos" created="Fri, 5 Jul 2019 16:53:54 +0200"  >&lt;p&gt;Also happens in 1.14.3 I had a hard time figuring out what&apos;s going on before I found this report. It&apos;s also a diagonal going on here but what I find interesting is that the comparator clock for the &lt;del&gt;hopper&lt;/del&gt;&#160;dropper works on one side but not the other, possibly due to update order. Manually I found out that by extending the wire by one it changes the behaviour&#160;&lt;a href=&quot;https://www.youtube.com/watch?v=LyFJE-DIMtQ&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://www.youtube.com/watch?v=LyFJE-DIMtQ&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="479274" author="alugia" created="Fri, 3 Aug 2018 00:36:25 +0200"  >&lt;p&gt;Still in 18w31a&lt;/p&gt;</comment>
                            <comment id="464374" author="superdyl" created="Wed, 27 Jun 2018 21:46:06 +0200"  >&lt;p&gt;Random order of updates to redstone dust still exists in 1.13-Pre4&lt;/p&gt;</comment>
                            <comment id="448123" author="shildifreak" created="Fri, 20 Apr 2018 22:55:57 +0200"  >&lt;p&gt;affects 18w16a&lt;/p&gt;</comment>
                            <comment id="426854" author="md_5" created="Thu, 4 Jan 2018 00:30:08 +0100"  >&lt;p&gt;I can&apos;t see any substantive changes&lt;/p&gt;</comment>
                            <comment id="426852" author="violine1101" created="Thu, 4 Jan 2018 00:12:47 +0100"  >&lt;p&gt;This appears to be partially fixed in 18w01a, can someone who has enough knowledge about how this works check please? It still looks weird to me, but that might be caused by QC, I&apos;m not entirely sure about that.&lt;/p&gt;</comment>
                            <comment id="420780" author="theosib2" created="Wed, 29 Nov 2017 06:32:16 +0100"  >&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;I have uploaded a fix for this bug.  Please find that and an explanation on &lt;a href=&quot;https://bugs.mojang.com/browse/MC-81098&quot; title=&quot;Redstone dust updates cause lag&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-81098&quot;&gt;MC-81098&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;Thanks.&lt;/p&gt;</comment>
                            <comment id="416523" author="JIRAUSER71590" created="Sun, 5 Nov 2017 09:29:58 +0100"  >&lt;p&gt;No, that&#8217;s &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="416521" author="nerdtality" created="Sun, 5 Nov 2017 09:26:00 +0100"  >&lt;p&gt;I believe this is the bug that adds the unintended &quot;BUD&quot; feature with pistions which is much loved.&lt;/p&gt;</comment>
                            <comment id="416469" author="oxygenchen" created="Sat, 4 Nov 2017 22:39:22 +0100"  >&lt;p&gt;Confirmed for 1.12.2&lt;/p&gt;</comment>
                            <comment id="375595" author="mathe172" created="Sun, 2 Apr 2017 17:27:42 +0200"  >&lt;p&gt;@Mark Jovelle C. Sulibaga: If you read the part above the conclusions, you&apos;ll see that the cause was never questioned - the problem is the &quot;randomness&quot; of the unpowering order of redstone dust causes problems&lt;/p&gt;</comment>
                            <comment id="375593" author="mark jovelle" created="Sun, 2 Apr 2017 17:21:24 +0200"  >&lt;p&gt;I think this is the effect of BUD pistons because since BUDs don&apos;t realize that they are powered until a block update is performed, the BUD will be stuck in its current position, if it was powered it will remain like that and since in the video presented does not place a block  beside the piston and a block near it is powered, it won&apos;t realized its powered state.&lt;/p&gt;</comment>
                            <comment id="346000" author="pokechu22" created="Sat, 26 Nov 2016 03:38:11 +0100"  >&lt;p&gt;The age of the issue has nothing to deal with how soon it can be fixed.  This issue in particular is &lt;em&gt;very hard&lt;/em&gt; to fix (and will probably require a major rework of most of the redstone code).  It&apos;s not like you can just say, &quot;I want to fix &lt;a href=&quot;https://bugs.mojang.com/browse/MC-11193&quot; title=&quot;The order in which powerable blocks (e.g. redstone dust blocks) along a wire are powered or de-powered is not clearly defined and causes a non-deterministic behavior for redstone contraptions&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-11193&quot;&gt;MC-11193&lt;/a&gt;&quot; today, and it&apos;ll magically be fixed.&lt;/p&gt;</comment>
                            <comment id="345999" author="xylandor" created="Sat, 26 Nov 2016 03:32:43 +0100"  >&lt;p&gt;Wow, Mojang. Any idea when you&apos;re going to get around to fixing this THREE YEAR OLD ISSUE!!!!&lt;/p&gt;</comment>
                            <comment id="333524" author="fm22" created="Thu, 6 Oct 2016 14:29:24 +0200"  >&lt;p&gt;I&apos;m glad you&apos;re working on this.&lt;/p&gt;</comment>
                            <comment id="324484" author="daisybates" created="Wed, 10 Aug 2016 00:51:03 +0200"  >&lt;p&gt;My ticket (105937) was flagged as a duplicate of this one, so I&apos;ll add to this. &lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://twitter.com/SirMrDaisyBates/status/762842999189417984&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://twitter.com/SirMrDaisyBates/status/762842999189417984&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Above is the video of it I posted on Twitter.&lt;/p&gt;

&lt;p&gt;I was in the process of building the Iron Titan in my single player world. I built it to spec and followed TangoTek&apos;s 1.9+ updated design.&lt;/p&gt;

&lt;p&gt;Using the original design, the dispenser seemed to fire correctly. Once I upgraded to the design he suggested for 1.9+, the dispenser would fire only one time after applying the redstone dust. After the very first time, it would never fire again despite it receiving a pulse. The interesting thing was, if I broke the dust and replaced it, it would fire correctly upon the next pulse, yet it would not fire again after that one time. The same was also true if I extended the redstone dust to the next block over (updating the dust that way seemed to make it fire successfully one time, then break).&lt;/p&gt;

&lt;p&gt;I did my best to look over the build. I haven&apos;t seen any indirect powering or anything like that that may possibly lock the dispenser some how (though I&apos;m not too great with indirect/bud stuff). I&apos;m baffled.&lt;/p&gt;

&lt;p&gt;I did do a fly around of it towards the end of the video. I receive the same results with or without optifine, so I do not believe it is a factor.&lt;/p&gt;</comment>
                            <comment id="321147" author="fm22" created="Sun, 17 Jul 2016 10:21:47 +0200"  >&lt;p&gt;This ticket would be so much less serious if &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt; wasn&apos;t a thing: the green-and-purple-wool example here and &lt;a href=&quot;https://bugs.mojang.com/browse/MC-105150&quot; title=&quot;Dispenser Not Working Some of the Time&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-105150&quot;&gt;&lt;del&gt;MC-105150&lt;/del&gt;&lt;/a&gt; wouldn&apos;t be problems. Conversely, &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt; is made more confusing to learn as a &quot;useful feature&quot; by this bug because it always seems to crop up near quasi-connectivity. The 2 bugs together cause many more problems than each individually.&lt;/p&gt;</comment>
                            <comment id="320113" author="someone3x7" created="Sat, 9 Jul 2016 00:47:34 +0200"  >&lt;p&gt;Noticed suggestions being tossed around on this in my email. Conceptually dust has no timing, so a segmented list of dust structures would make more sense. If a dust segment/structure gets activated all input components on its list get an update scheduled in the order of distance from the activated output. In certain situations this would cause significantly more memory usage, yet, those situations should be rare. Sorry if my explanation is unclear. Communicating my thoughts is becoming increasingly more difficult.&lt;/p&gt;</comment>
                            <comment id="320110" author="bugi74" created="Fri, 8 Jul 2016 22:54:23 +0200"  >&lt;p&gt;... and, by the sound of it, Panda is approaching towards both the proper solutions I suggested in the first comment. &lt;/p&gt;

&lt;p&gt;&quot;to first evaluate and set the new state of the whole wire and then cause each update just once along the wire.&quot; is at least part of the case 1; the idea is to store all &quot;current state&quot; separate from all &quot;next state&quot;, then change all the states at once. Apply this to the whole block set reachable via blocks (or other effects, should there be some day things that cause effects instantly &quot;over the air&quot;) that will or can change state within the same tick.&lt;/p&gt;

&lt;p&gt;And &quot;As the mod already works with sets of wire positions, it would be possible to make some adjustments to allow triggering the algorithm with several wire positions instead of just one. So all wires around a lever could be added to the set, before the algorithm starts working.&quot; would be part of the case 2, even if it doesn&apos;t use the same terms or data structures.  Idea is to build a directed graph of connections between affected/affecting entities (or groups of entities to simplify e.g. wire handling). The minor challenge is to keep that graph correct when the things change (or chunks get unloaded/loaded), but the actual runtime simulation becomes near trivial.&lt;/p&gt;

&lt;p&gt;It really would be easiest simply to go full throttle with the EE-simulation basics; all the current problems would be gone just like that. Bad sides could be memory use (depending, it might still be insignificant compared to everything else, and in some cases could even use less memory), and how to implement it with the dynamically loaded/unloaded chunks (i.e. circuits can be &quot;cut&quot; but should still do something with the parts that are loaded).&lt;/p&gt;

&lt;p&gt;Also, I haven&apos;t given a single thought on trying to keep weird existing behaviors intact (like BUDs and such); keeping them &quot;as is&quot; might require some extra rules, like exceptionally using other &quot;next state&quot; info as input data when calculating some block type&apos;s output &quot;next state&quot;, etc.&lt;/p&gt;


&lt;p&gt;All that said, nice effort trying to tackle this bug, Panda! I welcome any and all changes that improve things, even a bit, and removing the non-deterministic things is a big step.&lt;/p&gt;</comment>
                            <comment id="320079" author="panda4994" created="Fri, 8 Jul 2016 19:43:30 +0200"  >&lt;p&gt;As pointed out by &lt;a href=&quot;https://bugs.mojang.com/secure/ViewProfile.jspa?name=md_5&quot; class=&quot;user-hover&quot; rel=&quot;md_5&quot;&gt;md_5&lt;/a&gt; replacing the non-order-keeping HashSet with a oder-keeping one (e.g. LinkedHashSet) would make it symmetric regarding changes in position.&lt;br/&gt;
But the order would still be very directional and counterintuitive.&lt;/p&gt;

&lt;p&gt;Also when fixing it, unnecessary block updates should be reduced (see &lt;a href=&quot;https://bugs.mojang.com/browse/MC-81098&quot; title=&quot;Redstone dust updates cause lag&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-81098&quot;&gt;MC-81098&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;A possible way to update redstone in an &quot;along the wire&quot;-order and remove the performance issue on unpowering it, would be to first evaluate and set the new state of the whole wire and then cause each update just once along the wire.&lt;br/&gt;
The problematic case when turning off a wire that&apos;s still powered from an other source could be solved by turning off all connected wires (all that get powered by this one anyways) first.&lt;br/&gt;
When all of them are off they get turned back on starting from the other power sources.&lt;/p&gt;

&lt;p&gt;I attempted to implement such a solution.&lt;br/&gt;
Mod: &lt;a href=&quot;http://www.mediafire.com/download/okhobwmcj4e8jqa/1.10_RedstoneFix.zip&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.mediafire.com/download/okhobwmcj4e8jqa/1.10_RedstoneFix.zip&lt;/a&gt;&lt;br/&gt;
Code: &lt;a href=&quot;https://gist.github.com/Panda4994/70ed6d39c89396570e062e4404a8d518&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://gist.github.com/Panda4994/70ed6d39c89396570e062e4404a8d518&lt;/a&gt;&lt;br/&gt;
Video: &lt;a href=&quot;https://www.youtube.com/watch?v=NEMARMNvDsw&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://www.youtube.com/watch?v=NEMARMNvDsw&lt;/a&gt;&lt;/p&gt;


&lt;p&gt;The main goals of the implementation were:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Reduce unnecessary updates&lt;/li&gt;
	&lt;li&gt;Make the update order more logical and predictable&lt;/li&gt;
	&lt;li&gt;Keep old behaviour working&lt;/li&gt;
&lt;/ul&gt;



&lt;p&gt;Some of the changes made in the mod are simple improvements and I doubt they have downsides.&lt;br/&gt;
For example when the blocks around the wire get updated it used to update all surrounding blocks of all surrounding blocks and itself.&lt;br/&gt;
So each time a wire updates its neighbors 42 block updates are caused, while 18 of them are repetitive (17 if the update on itself is needed).&lt;br/&gt;
To avoid that I made a static List of Vec3i containing the offsets of the positions that need to be updated.&lt;/p&gt;


&lt;p&gt;However, other changes are a bit weird or imply some follow-up changes on other redstone components.&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;The entire wire changes its state before causing any updates.&lt;br/&gt;
This quite a change but in the 1.9 update the same was done to pistons, so it seems logical to apply it to redstone too.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;Needed updates are caused first&lt;br/&gt;
In the mod blocks that actually get powered by the wire get updated first.&lt;br/&gt;
To do so I created a method canBlockBePoweredFromSide() which checks if a block can receive redstone power from a certain side.&lt;br/&gt;
At the moment it is a bunch of instanceof-cases for all blocks that have special behaviour regarding redstone.&lt;br/&gt;
If this was actually adapted it should probably be changed to be a method of Block.java that gets overridden by the blocks with special behaviour regarding redstone and works with a fancy PowerSource-Enum and stuff like that.&lt;br/&gt;
There are two reasons why this is needed.&lt;br/&gt;
The first one is that there are cases where updates from the start of the wire could cause changes on blocks further back, making the order of changes less logical again.&lt;br/&gt;
&lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/attachment/121612/121612_JumpingUpdate.png&quot; width=&quot;30%&quot; style=&quot;border: 0px solid black&quot; /&gt;&lt;/span&gt;&lt;br/&gt;
The piston on the right is connected closer to the power source, but without this check the one on the left would receive an update first.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;The second reason for it is that not really needed updates are caused in a reverse order and after the needed ones.&lt;br/&gt;
This is probably the weirdest quirk in the mod.&lt;br/&gt;
The not-really-needed-updates are updates that will only have an effect on block update detectors.&lt;br/&gt;
The only reason I put them in is to keep old behaviours working. For the same reason they are in a backwards order, because that is closer to the order the recursive updates would have generated.&lt;br/&gt;
I know this is a weird and specific quirk, but I found a few (very timing specific) builds that would break if the order wasn&apos;t reversed for these updates.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;The updates travel from the first UPDATED wire outwards.&lt;br/&gt;
For example if there is a lever in the center of a diamond shape of redstone wire and you turn it on, you would probably expect the updates to wander out in a diamond shape as well.&lt;br/&gt;
However currently the wire west of the lever will turn on first, as it receives the initial update and then the diamond shape emerges from there.&lt;br/&gt;
&lt;span class=&quot;image-wrap&quot; style=&quot;&quot;&gt;&lt;img src=&quot;https://bugs.mojang.com/secure/attachment/121611/121611_DiamondShape.gif&quot; width=&quot;30%&quot; style=&quot;border: 0px solid black&quot; /&gt;&lt;/span&gt;&lt;br/&gt;
This is something that&apos;s not perfect with the mod yet, but changing it would require to change how other blocks trigger redstone updates.&lt;br/&gt;
As the mod already works with sets of wire positions, it would be possible to make some adjustments to allow triggering the algorithm with several wire positions instead of just one.&lt;br/&gt;
So all wires around a lever could be added to the set, before the algorithm starts working.&lt;br/&gt;
In case this idea would be considered, there might be many more elements on the lists in some cases.&lt;br/&gt;
So it might be necessary to replace the current use of lists and contains calls as set with a remove-first-method with something with a less expensive contains implementation.&lt;/li&gt;
&lt;/ul&gt;


&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;The updates around a single wire also follow a closest-first order.&lt;br/&gt;
This is not so much a problem than rather a logical conclusion from the decision to make the update order logical.&lt;br/&gt;
But it feels inconsistent with how other redstone components currently update their surrounding blocks.&lt;br/&gt;
So I think if this fix was used, other redstone components such as repeaters or torches, should use an update order following the same principles.&lt;br/&gt;
However this would break quite a few old designs, as repeaters and torches already follow an order. (Other than redstone wire for which the order was basically random before, which gives the freedom to just decide on a good order without breaking designs)&lt;/li&gt;
&lt;/ul&gt;



&lt;p&gt;This is the main concerns I have with this fix, but I would like to get some feedback on it.&lt;br/&gt;
Also I would be interested in finding designs that worked position independent before, but won&apos;t work in the fix. I tried quite a few huge and fast builds, but the only things that broke were positional before, so it&apos;s unavoidable for them when fixing this bug.&lt;/p&gt;</comment>
                            <comment id="318984" author="bugi74" created="Sat, 2 Jul 2016 09:59:38 +0200"  >&lt;p&gt;Using list will not be a good or a full fix. It could store the same block multiple times, leading to inefficiencies if not worse things. The set is used due to its &quot;mathematical&quot; property of storing each to-be-handled block only once.&lt;/p&gt;

&lt;p&gt;Also, even if the list would not have random order based on block&apos;s location, it would still suffer from sub-tick issues (unless Mojang did something to these, I have vague memories of some related changes).&lt;/p&gt;

&lt;p&gt;The first comment (mine) should clarify a bit. The real solution lies in using a separate input and output states (per block), instead of sharing single state (per block) for both input and output. After that, it doesn&apos;t matter how and in which order the logic is calculated inside a tick.&lt;/p&gt;</comment>
                            <comment id="318981" author="fm22" created="Sat, 2 Jul 2016 09:02:25 +0200"  >&lt;p&gt;I suppose directional is better than completely random.&lt;/p&gt;</comment>
                            <comment id="318965" author="md_5" created="Sat, 2 Jul 2016 06:36:22 +0200"  >&lt;p&gt;Fix for this is quite simple. RedstoneWire uses a non-deterministic Set to store block update positions. Just changing this to a List (funnily enough the code creates temporary lists from this set already) will fix the issue.&lt;/p&gt;</comment>
                            <comment id="312064" author="firefish5000" created="Thu, 9 Jun 2016 09:18:42 +0200"  >&lt;p&gt;In addition, this odd setup also acts as a bud, but relies on chunk boarders. (red/white should be in different chunks. Replace dropper with piston for better visual)&lt;br/&gt;
Image:&lt;br/&gt;
&lt;a href=&quot;https://drive.google.com/file/d/0BxOpmZr8Qp5cSjRkNjBySHZ3WTA/view?usp=sharing&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://drive.google.com/file/d/0BxOpmZr8Qp5cSjRkNjBySHZ3WTA/view?usp=sharing&lt;/a&gt;&lt;br/&gt;
Scematic:&lt;br/&gt;
&lt;a href=&quot;https://drive.google.com/open?id=0BxOpmZr8Qp5cb19nNC0yeWpqb0k&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://drive.google.com/open?id=0BxOpmZr8Qp5cb19nNC0yeWpqb0k&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Note that the BUD updates when either a block is placed next to the piston, or when the redstone connecting to the piston and within the piston&apos;s chunk is destroyed. This redstone placement is unrelated to the one mentioned above, since we rely on chunk boarders hear.&lt;/p&gt;

&lt;p&gt;FWIW, I like the idea of a BUD, but I fear that the way they are currently implemented (more of a side effect/bug of lazy updates than a feature) will cause more headaches than it will solve problems (kindly put, I&apos;m in bugy/BUDy hell). I wish they would reconsider BUD as a bug and create a new BUD block.&lt;/p&gt;</comment>
                            <comment id="308577" author="schnitzbert" created="Mon, 30 May 2016 22:45:38 +0200"  >&lt;p&gt;I also found this unresolved in 16w21b.&lt;/p&gt;</comment>
                            <comment id="301886" author="entereloaded" created="Wed, 27 Apr 2016 19:16:52 +0200"  >&lt;p&gt;@a a this is because the bug is created by budded Blocks next to the piston, not the Blocks above, so if the diagobally above Blocks are not Solid they don&apos;t create a Bud and in consequence everything works.&lt;/p&gt;</comment>
                            <comment id="301883" author="aldaf" created="Wed, 27 Apr 2016 19:11:50 +0200"  >&lt;p&gt;Affects 1.9.3-pre2... Interestingly, when using upsidedown slabs instead of solid blocks to power pistons below, they retract as intended...&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://gfycat.com/SlimyWellgroomedDikdik&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://gfycat.com/SlimyWellgroomedDikdik&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Edit: i know why it works that way given this bug, just found it interesting and it might be a workaround for some people, given this seems unlikely to be fixed soon&lt;/p&gt;</comment>
                            <comment id="300336" author="aldaf" created="Fri, 15 Apr 2016 18:23:53 +0200"  >&lt;p&gt;still affects 16w15b&lt;/p&gt;</comment>
                            <comment id="299713" author="jeuvke" created="Mon, 11 Apr 2016 22:04:12 +0200"  >&lt;p&gt;This bug makes is basically impossible to power a compact water dispenser setup to break the portals in a nether portal gold farm.&lt;/p&gt;</comment>
                            <comment id="299338" author="aldaf" created="Sat, 9 Apr 2016 20:48:17 +0200"  >&lt;p&gt;confirmed for 16w14a: pistons randomly stay extended, effect is worse when redstone is in a grid (see 2016-04-09_20.26.08.png)&lt;/p&gt;</comment>
                            <comment id="294778" author="bcnofnenamg" created="Sun, 13 Mar 2016 20:56:38 +0100"  >&lt;p&gt;Confirmed for 1.9.1-pre1, pre2, and pre3&lt;/p&gt;</comment>
                            <comment id="292190" author="oninoni" created="Thu, 3 Mar 2016 21:43:03 +0100"  >&lt;p&gt;Confirmed for 1.9...&lt;/p&gt;</comment>
                            <comment id="243910" author="blackstar7713" created="Wed, 19 Aug 2015 22:54:27 +0200"  >&lt;p&gt;Confirmed for 15w33c, not yet fixed in current 1.9 devbuilds&lt;/p&gt;</comment>
                            <comment id="231759" author="fm22" created="Sat, 20 Jun 2015 15:15:45 +0200"  >&lt;p&gt;Confirmed for 1.8.7: The left setup fires all items; the right setup doesn&apos;t. This is because of either the redstone wire next to the bottom dropper or the one at the very top (I&apos;m not sure) updating sometimes before and sometimes after their respective droppers and dispensers&lt;/p&gt;</comment>
                            <comment id="225066" author="_death_star_" created="Sat, 18 Apr 2015 23:52:51 +0200"  >&lt;p&gt;1.8.4 has this bug&lt;/p&gt;</comment>
                            <comment id="223031" author="_death_star_" created="Thu, 26 Mar 2015 14:24:34 +0100"  >&lt;p&gt;1.8.3 has this bug&lt;/p&gt;</comment>
                            <comment id="208394" author="the.modificator" created="Sun, 9 Nov 2014 13:08:00 +0100"  >&lt;p&gt;Aaron, this ticket is not about that issue. This ticket is about the issue that the order in which powerable blocks (e.g. redstone dust blocks) along a wire are powered or de-powered is not clearly defined and causes a non-deterministic behavior for redstone contraptions. Please check the title, the description and the video demonstration.&lt;/p&gt;</comment>
                            <comment id="202993" author="redstonehelper" created="Fri, 10 Oct 2014 22:04:03 +0200"  >&lt;p&gt;Another way to replicate this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/tp @p 1216 17 -634&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/fill ~10 ~10 ~10 ~-10 ~-10 ~-10 air&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/setblock 1216 17 -634 minecraft:piston&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/setblock 1216 18 -634 minecraft:melon_block&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/setblock 1215 18 -634 minecraft:melon_block&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/setblock 1214 18 -634 minecraft:lever 10&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/setblock 1215 19 -634 minecraft:redstone_wire&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/setblock 1216 19 -634 minecraft:redstone_wire&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Then toggle the lever and observe the piston not retract. The same setup will retract the piston in other locations.&lt;/p&gt;</comment>
                            <comment id="199315" author="th3dutcher" created="Wed, 10 Sep 2014 22:06:01 +0200"  >&lt;p&gt;Confirmed for 1.8.&lt;/p&gt;</comment>
                            <comment id="161022" author="marcono1234" created="Sat, 31 May 2014 17:48:27 +0200"  >&lt;p&gt;Relates to: &lt;a href=&quot;https://bugs.mojang.com/browse/MC-50187&quot; title=&quot;redstone updates inconsistent based on location&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-50187&quot;&gt;&lt;del&gt;MC-50187&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="158707" author="marcono1234" created="Mon, 19 May 2014 19:22:50 +0200"  >&lt;p&gt;Confirmed for 14w20b&lt;br/&gt;
Please update your discription &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="146208" author="haydenmuhl" created="Tue, 11 Mar 2014 09:17:00 +0100"  >&lt;p&gt;Confirming for 1.7.5. &lt;/p&gt;</comment>
                            <comment id="139672" author="garyclosse" created="Tue, 11 Feb 2014 08:20:02 +0100"  >&lt;p&gt;Still in 06b (&lt;a href=&quot;https://bugs.mojang.com/browse/MC-47986&quot; title=&quot;No pistonretraction when triggered from top&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-47986&quot;&gt;&lt;del&gt;MC-47986&lt;/del&gt;&lt;/a&gt;)&lt;/p&gt;</comment>
                            <comment id="114703" author="frod" created="Thu, 24 Oct 2013 23:35:48 +0200"  >&lt;p&gt;still in 1.7.1&lt;/p&gt;</comment>
                            <comment id="101833" author="frod" created="Mon, 9 Sep 2013 15:06:08 +0200"  >&lt;p&gt;Still in 13w36b&lt;/p&gt;</comment>
                            <comment id="93190" author="bugi74" created="Sat, 20 Jul 2013 15:58:51 +0200"  >&lt;p&gt;I just checked the code of 1.6.1 (and I have no reason to believe it would not be the same in 1.6.2), and the reason is indeed the same as it was years ago. It is as I described in the first comment: redstone wire signal propagation to other blocks is stored temporarily in a _hash_set and the hashing is based on the location. This gives, in practice, different (seemingly random) results in different locations/setups/orientations.&lt;/p&gt;

&lt;p&gt;There are also other reasons for the non-deterministic redstone behavior, but they would be other issues. Since full deterministic behavior would require fixing them all, I will not provide a fix for this issue. It would be better (and easier) to simply rewrite redstone logic code from scratch.&lt;/p&gt;</comment>
                            <comment id="93137" author="frod" created="Sat, 20 Jul 2013 11:14:02 +0200"  >&lt;p&gt;pic of the bug that I described really bad in my previous comment: imgur.com/nLiVvG0.png&lt;/p&gt;</comment>
                            <comment id="93027" author="torabi" created="Sat, 20 Jul 2013 00:53:45 +0200"  >&lt;p&gt;frod, the behavior you&apos;re describing is a different bug, reported at &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt;. Mojang is quite aware of these bugs.&lt;/p&gt;</comment>
                            <comment id="93002" author="frod" created="Fri, 19 Jul 2013 23:59:01 +0200"  >&lt;p&gt;It&apos;s still there in 1.6.2 and as a redstoner I find this really annoying... if you power a piston facing down with a block on top and redstone on top of that block, there&apos;s an unpredictable chance that the piston will never retract. Same with dispensers and droppers. Can a mod please make mojang aware of this bug?&lt;/p&gt;</comment>
                            <comment id="68949" author="yaugzebul" created="Sun, 26 May 2013 18:35:09 +0200"  >&lt;p&gt;Still in 13w21a&lt;/p&gt;</comment>
                            <comment id="62725" author="yaugzebul" created="Mon, 22 Apr 2013 21:16:56 +0200"  >&lt;p&gt;Still in 13w16a&lt;br/&gt;
Some love from a developer ? (Jeb ? dinnerbone ?)&lt;/p&gt;</comment>
                            <comment id="51013" author="red" created="Fri, 8 Mar 2013 16:14:50 +0100"  >&lt;p&gt;Just wanted to add that I&apos;ve noticed this always happens on row 0 of the x chunks: the effect can be reproduced constantly if found build a z row for every row 0 of any x chunk.&lt;/p&gt;

&lt;p&gt;I haven&apos;t found anything significant regarding z repeptetivity yet though.&lt;/p&gt;

&lt;p&gt;Furthermore, I&apos;ve found behaviour of the activation can be diffent if coming from the side (as demonstrated in the video and images provided bu the reporter) and from the top (using block with a lever on top, activating the redstone) ie: sometimes they act the same, sometimes the switch on top works, but not the side one; sometimes the side works, but the top doesn&apos;t! The &quot;effect&quot; remains constant depending on your z location (respecting the x chunk rule mentioned above).&lt;/p&gt;</comment>
                            <comment id="50916" author="fibonatic" created="Fri, 8 Mar 2013 02:36:24 +0100"  >&lt;p&gt;This also affects 13w10a (but not any snapshots before it), hopefully this helps figuring out what is causing this.&lt;/p&gt;

&lt;p&gt;I also noticed this bug today and made video about it (since I though it hadn&apos;t been posted): &lt;a href=&quot;http://www.youtube.com/watch?v=KM9DNfxBogw&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.youtube.com/watch?v=KM9DNfxBogw&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="50911" author="banana478" created="Fri, 8 Mar 2013 02:10:45 +0100"  >&lt;p&gt;Confirmed.&lt;/p&gt;</comment>
                            <comment id="50836" author="the.modificator" created="Thu, 7 Mar 2013 21:33:44 +0100"  >&lt;p&gt;Yeah, that looks like it is the same bug. I haven&apos;t tested my setup on 1.5 yet but - based on your comment - will add 1.5 as an affected version now.&lt;/p&gt;</comment>
                            <comment id="50734" author="yaugzebul" created="Thu, 7 Mar 2013 17:55:14 +0100"  >&lt;p&gt;I think this one is more here than in &lt;a href=&quot;https://bugs.mojang.com/browse/MC-108&quot; title=&quot;Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks above&quot; class=&quot;issue-link&quot; data-issue-key=&quot;MC-108&quot;&gt;&lt;del&gt;MC-108&lt;/del&gt;&lt;/a&gt;. (strange_behaviour.png)&lt;br/&gt;
In my map, if you activate upper or lower lever-&amp;gt;the left piston is activated first and the other one after.&lt;br/&gt;
I you activate the lever in the middle, it makes the right piston to be activated first.&lt;/p&gt;

&lt;p&gt;As the OP said, it is really strange. I would understand if the nearer the lever is to the second piston, the more it is prone to activate it, but here, it is random.&lt;/p&gt;

&lt;p&gt;If you want this map, just ask, I&apos;ll be glad to give it.&lt;/p&gt;

&lt;p&gt;Still happening in 1.5 pre-release.&lt;/p&gt;

</comment>
                            <comment id="50668" author="the.modificator" created="Thu, 7 Mar 2013 12:50:34 +0100"  >&lt;p&gt;For all people who don&apos;t want to read that long text I wrote for the description: Simply take a look at this video I made -&amp;gt; &lt;a href=&quot;http://www.youtube.com/watch?v=e5hUYLC8Tms&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.youtube.com/watch?v=e5hUYLC8Tms&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="50597" author="bugi74" created="Thu, 7 Mar 2013 02:45:49 +0100"  >&lt;p&gt;&quot;IMO, the best resolution would be to simply &quot;follow&quot; the wire and update the power level step-by-step &quot;on the way&quot;. This would also reflect real-world power currents best in this case. (Or to put it differently: You would also most likely expect this to happen based upon your real-world experience with power currents.)&quot;&lt;/p&gt;

&lt;p&gt;Alas, real world works super-parallel, allowing following multiple wire branches perfectly simultaneously etc.  That &quot;follow the wire&quot; behavior at least &lt;em&gt;was&lt;/em&gt; used by redstone logic before, and would have worked right if it would have first checked what it leads to and then update only those targets, and if there were no branches, and if the results states were stored in a buffer first. Alas, updates were handled as usual, and branches exist, and there was no temporary buffer.&lt;/p&gt;

&lt;p&gt;The propagation of the signal along the wire was handled with a hash-set; every seen neighbor wire to continue the signal to was put into the hash-set, and, in a loop, one-by-one unhandled parts were taken from that set. IIRC, the hash-set key depended on the block&apos;s location, and hash-sets are well known to utilize random-like distribution of the keys, and thus the iteration order is sort of random-like, too... Ring any bells? Depends on location, varies, ...&lt;/p&gt;

&lt;p&gt;One more mistake was that change results from one calculation during a &quot;tick&quot; were written directly back into world, from which also the input was taken for further calculations for the &lt;em&gt;same&lt;/em&gt; &quot;tick&quot;. This can (and often does) lead to incorrect input states for the latter parts of calculations in the same &quot;tick&quot;... Most of the time this was hidden with the delays of each redstone component, but when one started doing more complex things with feedbacks etc., the effects of these sub-tick timing dependencies and state changes started to show up.&lt;/p&gt;

&lt;p&gt;There are two proper ways to handle these kinds of things. (Well, two ways that come to my mind, might be more..)&lt;br/&gt;
1) Have a separate copy of block states to store the results into; then flip the results to current states once the tick has been calculated through. (There are tricks to reduce the size of that result buffer, or alternately, one can just flip the active vs. result state designation between the buffers (like double-buffering display graphics stuff). (As an easier exercise for this, implement &quot;game of life&quot; properly..) (Edit2: Forgot to mention, after buffering the results, the order of doing things during the tick doesn&apos;t matter; hash-sets should be ok.)&lt;br/&gt;
2) Convert redstone blocks into graphs (&apos;netlists&apos; and &apos;components&apos; etc.) for simulation, and ask a EE-student to finish the implementation. Gain several advantages and silly jokes about having an electronics circuit simulator inside a world simulator... (Edit: forgot, one still needs the result state buffers, but now they can be based on components instead of blocks).&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10102">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="24047">MC-10174</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="24637">MC-10667</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25299">MC-11190</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25390">MC-11274</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25499">MC-11370</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25566">MC-11430</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25627">MC-11482</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25648">MC-11503</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25758">MC-11598</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25911">MC-11680</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25936">MC-11705</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="26782">MC-12051</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="26831">MC-12094</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27120">MC-12290</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27157">MC-12325</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27207">MC-12371</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27307">MC-12464</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27323">MC-12475</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27430">MC-12579</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27431">MC-12580</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27446">MC-12595</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27726">MC-12828</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27846">MC-12935</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="29601">MC-14326</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="29978">MC-14559</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="31480">MC-15713</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="32449">MC-16595</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="33013">MC-17071</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="35613">MC-17603</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="36503">MC-18203</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="37303">MC-18820</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="42932">MC-23725</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="43308">MC-24055</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="44891">MC-25487</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="45718">MC-26178</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="46115">MC-26538</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="46690">MC-26919</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="47523">MC-27584</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="50521">MC-29430</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="53995">MC-32577</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="54010">MC-32591</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="55877">MC-34201</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="56898">MC-35173</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="60140">MC-37969</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="60427">MC-38217</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="62931">MC-40366</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="68808">MC-44168</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="71456">MC-45889</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="72948">MC-47304</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="73086">MC-47425</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="73658">MC-47986</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="76019">MC-50187</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="78639">MC-52535</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="78752">MC-52627</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="79895">MC-53657</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="82708">MC-56184</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="83047">MC-56474</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="83944">MC-56793</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="83966">MC-56813</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="89217">MC-61900</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="91082">MC-63687</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="97477">MC-69833</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="106721">MC-77958</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="107489">MC-78600</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="108495">MC-79413</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="108622">MC-79499</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="108703">MC-79544</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="112041">MC-81609</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="112481">MC-81916</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="113027">MC-82221</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="118407">MC-86409</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="120113">MC-87735</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="120402">MC-87945</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="127664">MC-93331</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="130496">MC-95019</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="131858">MC-95924</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="132035">MC-96025</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="135240">MC-97726</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="136606">MC-98806</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="137249">MC-99315</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="137548">MC-99579</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="137566">MC-99596</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="139109">MC-100797</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="139817">MC-101281</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="140030">MC-101417</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="145967">MC-105005</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="147561">MC-105937</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="147893">MC-106188</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="148505">MC-106592</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="149223">MC-106926</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="151360">MC-108379</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="151910">MC-108745</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="153412">MC-109551</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="153582">MC-109666</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="156445">MC-110740</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="159119">MC-111991</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="160030">MC-112365</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="165148">MC-114495</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="167156">MC-115400</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="167834">MC-115784</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="169646">MC-116805</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="170336">MC-117170</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="172888">MC-118431</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="173716">MC-118793</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="174352">MC-119038</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="175905">MC-119480</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="180439">MC-120584</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="189376">MC-123688</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="189380">MC-123689</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="194330">MC-126458</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="201019">MC-129832</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="207181">MC-133317</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="209424">MC-134679</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="211522">MC-135885</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="211658">MC-135946</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="214934">MC-137148</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="215239">MC-137223</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="222403">MC-141389</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="222576">MC-141466</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="225579">MC-143193</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="231227">MC-145954</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="233336">MC-147057</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="243855">MC-153287</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="252238">MC-157479</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="260601">MC-161248</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="272359">MC-165799</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="272744">MC-165894</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="274009">MC-166373</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="281845">MC-169041</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="295803">MC-174962</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="310356">MC-179787</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="316814">MC-182072</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="318073">MC-182463</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="332962">MC-187142</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="338716">MC-189775</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="344706">MC-191978</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="346902">MC-192538</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="363129">MC-197654</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="368624">MC-199134</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="371499">MC-199967</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="376090">MC-201385</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="378964">MC-202272</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="379623">MC-202479</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="406103">MC-212052</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="420117">MC-218584</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="428732">MC-222265</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="434423">MC-224264</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="450612">MC-230628</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="456717">MC-232813</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="472994">MC-238461</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="478812">MC-240201</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="492424">MC-247027</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="496671">MC-249004</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="497755">MC-249644</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="498286">MC-249906</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="503958">MC-252135</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="507731">MC-253442</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="512013">MC-254816</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="517210">MC-256241</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="525052">MC-259288</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="526239">MC-259782</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="528701">MC-260790</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="529299">MC-260985</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="531835">MC-261858</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="536046">MC-263355</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="537468">MC-263819</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="541722">MC-265082</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="563099">MC-274253</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="570270">MC-277147</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="42074">MC-22926</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10103">
                    <name>Relates</name>
                                            <outwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="318047">MC-182452</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="326345">MC-185208</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="23451">MC-9714</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="188521">MC-123311</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="11353">MC-108</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="23729">MC-9955</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25774">MC-11613</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="64118">MC-41006</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="80881">MC-54567</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="359706">MC-196370</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25589">MC-11449</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="50521">MC-29430</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="66398">MC-42368</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="103697">MC-75514</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="153828">MC-109799</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                            <attachment id="92564" name="2015-06-20_14.03.08.png" size="755453" author="FM22" created="Sat, 20 Jun 2015 15:15:45 +0200"/>
                            <attachment id="115532" name="2016-04-09_20.26.08.png" size="638276" author="aldaf" created="Sat, 9 Apr 2016 20:48:17 +0200"/>
                            <attachment id="309347" name="2020-06-15_14.39.08.png" size="1180566" author="frankiefan123" created="Mon, 15 Jun 2020 15:39:53 +0200"/>
                            <attachment id="309348" name="2020-06-15_14.39.10.png" size="1166761" author="frankiefan123" created="Mon, 15 Jun 2020 15:39:54 +0200"/>
                            <attachment id="309349" name="2020-06-15_14.45.20.png" size="745963" author="frankiefan123" created="Mon, 15 Jun 2020 15:46:34 +0200"/>
                            <attachment id="309350" name="2020-06-15_14.45.32.png" size="746522" author="frankiefan123" created="Mon, 15 Jun 2020 15:46:34 +0200"/>
                            <attachment id="309351" name="2020-06-15_14.45.56.png" size="745127" author="frankiefan123" created="Mon, 15 Jun 2020 15:46:34 +0200"/>
                            <attachment id="309352" name="2020-06-15_14.46.09.png" size="743235" author="frankiefan123" created="Mon, 15 Jun 2020 15:46:33 +0200"/>
                            <attachment id="121611" name="DiamondShape.gif" size="708002" author="panda4994" created="Fri, 8 Jul 2016 19:43:30 +0200"/>
                            <attachment id="121612" name="JumpingUpdate.png" size="32336" author="panda4994" created="Fri, 8 Jul 2016 19:43:30 +0200"/>
                            <attachment id="121660" name="MC-11193.zip" size="225171" author="pokechu22" created="Sat, 9 Jul 2016 06:10:33 +0200"/>
                            <attachment id="23721" name="basic-setup-1.png" size="363215" author="the.modificator" created="Thu, 7 Mar 2013 02:24:57 +0100"/>
                            <attachment id="23722" name="basic-setup-2.png" size="820318" author="the.modificator" created="Thu, 7 Mar 2013 02:24:57 +0100"/>
                            <attachment id="309346" name="image-2020-06-15-14-39-29-919.png" size="1180566" author="frankiefan123" created="Mon, 15 Jun 2020 15:39:31 +0200"/>
                            <attachment id="309354" name="image-2020-06-15-14-48-29-121.png" size="745963" author="frankiefan123" created="Mon, 15 Jun 2020 15:48:29 +0200"/>
                            <attachment id="309355" name="image-2020-06-15-14-48-46-781.png" size="746522" author="frankiefan123" created="Mon, 15 Jun 2020 15:48:47 +0200"/>
                            <attachment id="309356" name="image-2020-06-15-14-51-55-708.png" size="745127" author="frankiefan123" created="Mon, 15 Jun 2020 15:51:59 +0200"/>
                            <attachment id="309358" name="image-2020-06-15-14-52-17-953.png" size="743235" author="frankiefan123" created="Mon, 15 Jun 2020 15:52:18 +0200"/>
                            <attachment id="23770" name="strange_behaviour.png" size="149440" author="yaugzebul" created="Thu, 7 Mar 2013 17:55:14 +0100"/>
                    </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, 8 Mar 2013 02:11:00 +0100</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11901" key="com.atlassian.jira.plugin.system.customfieldtypes:multiselect">
                        <customfieldname>Category</customfieldname>
                        <customfieldvalues>
                                <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>170.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_11600" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i0e687:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_12201" key="com.atlassian.jira.plugin.system.customfieldtypes:datetime">
                        <customfieldname>Triaged Time</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Tue, 3 Sep 2019 09:25:18 +0200</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                </customfields>
    </item>
</channel>
</rss>