The presence of redstone lamps, droppers, dispensers, and command blocks in a device can change the behavior of observers and possibly other redstone components in the same device, despite that they should not be affecting them in any way.
Screenshots and a world download are attached.
The test world contains two identical test jigs. The first jig works as expected; the second one does not. Each time you build this jig in another location, there is a random chance that it will work as expected. Once built, a jig's behavior does not change; one that exhibits the problem always exhibits it in the same way, while one that doesn't exhibit the problem never exhibits it.
The test jig is designed to produce a sequence of 1-tick pulses out of the sideways facing observers, 1 tick apart, in order from bottom to top. It has a memory display at the top (on the green blocks) that records the pattern of output pulses from the top sideways facing observer. At the bottom of the jig is a red block on which a test component can be placed.
Expected behavior: The topmost sideways facing observer emits a 1-rtick pulse, regardless of what, if anything, is on the red block.
Actual behavior (in a jig that exhibits the problem): The output varies depending on which, if any, component is on the red block, and in the case of the command block, what its settings are set to.
Steps to reproduce: (repeat on each jig):
1. Ensure that the memory display is clear (break/replace the dust on the blue block).
2. Place a redstone lamp, dropper, dispenser, or command block on the red block, facing in any direction other than the observer. (See note below for command block settings). Alternatively, remove any component to test without one.
3. Toggle the lever.
4. Examine the memory display. Note that jig 1 always displays a single on-pulse, while jig 2 displays one of the following sequences of pulses:
Test Component | Output Sequence |
(none) | On (as expected) |
Redstone Lamp | On-On |
Dropper | On-Off-On |
Dispenser | On-Off-On |
Impulse Command Block | On-On-Off-On |
Repeat Command Block | On-Off-On |
5. As a test variation, break some combination of the 2nd through 5th sideways facing observers, counting from the bottom, and repeat the test. Note that the displayed pulse pattern may change. (I think that if you break both the 2nd and 3rd observers from the bottom, the problem disappears.) If no component is on the red block, breaking these observers has no effect on the output.
Note: The command block behavior depends on its settings. Not all settings cause unexpected output. Known settings which do include (Impulse, Unconditional, Needs Redstone) and (Repeat, Unconditional, Needs Redstone). It is not necessary to enter a command into the block.
Attachments
Comments 8
Here's something I think probably has the same cause. This is an observer-clocked droppervator, 32 blocks high. It successfully transfers the blocks all the way with no stuck items, but it clicks a few times anyway. I suspect it's because of the extra pulses (On-Off-On) that droppers can induce.
[media]
I have uploaded an additional world, MCPE-29243 test world 2.mcworld, which may be more useful for researching this issue. It has a single test jig with a separate memory display for each sideways-facing observer's output, so you can see how the pulse pattern evolves up the stack. It also has a convenient reset button for clearing all the memory displays at once, and command blocks to easily make additional copies of the jig (to demonstrate the randomness of whether a given jig exhibits the bug) and to remove unneeded copies.
I have done some additional testing with the second attached world (MCPE-29243 test world 2.mcworld) and have discovered that not only does the interference-causing mechanism not have to be on the red block or physically adjacent to the disturbed circuit, it doesn't even have to be "electrically" (redstone) connected to the disturbed circuit at all. Here is a screenshot of my modified jig showing how I tested this:
[media]
I performed the test by toggling the lever on the left to generate a pulse from the bottom observer, then quickly toggling the lever on the right to cause the mechanism to activate or deactivate before the pulse reaches the top observer.
The reported problem happens when a pulse is propagating through the observer stack and any of the following occurs:
A redstone lamp is deactivated or turns off
A dispenser or dropper is activated
An impulse command block is activated, or
A chain command block is either activated or deactivated
The problem only happens if the test mechanism is in the same chunk. It doesn't seem to matter whether the power source for that mechanism is in the same chunk, however.
This conclusively demonstrates that multiple redstone circuits within the same chunk can interfere with each other's operation in a way that the player cannot predict or control, even though they are not connected in any way. This is a definite malfunction that makes redstone inherently unreliable. I cannot imagine any way it could be considered intentional that redstone should work this way.
I have added a third demo world (
[media]) that demonstrates this bug. It is not as reliable at evoking the bug (you have to tweak the configuration), but it removes all the extraneous stuff, leaving a minimum case with maximum diagnostic value.
Toggling the lever causes the bottom observer to output a 1 rtick pulse up the stack of downward-facing observers. When the bug is active, this pulse becomes modified within the stack, either by being lengthened or by the introduction of extra pulses. This can be observed by watching the redstone torch at the top; it should blink off for 1 rtick unless the configuration evokes the bug, in which case it will blink off for a longer time or multiple times. In case detecting the difference between 1 and 2 rticks by eye is too difficult, a second torch is also provided; it will blink on if the pulse lasts 2 rticks or longer. The second torch and its associated repeater can be removed if not needed.
Tweaks include replacing the redstone lamp with a dispenser, dropper, or command block; changing the delay setting of the repeater that powers it; and changing the number and positions of sideways-facing observers adjacent to the stack.
The easiest way to find a bugged configuration is to place sideways observers at every level, then try different repeater delay settings until the bug appears. (You should test each configuration twice, because the bug only appears when the lamp turns off or one of the other mechanisms becomes activated.) You can then experiment with removing different combinations of sideways observers if you want to know which are involved with this configuration. (There is a direct correlation between repeater delay settings and height of the involved observers, but some configurations require only one observer while others require two, one above the other.)
Note: I tried to reproduce the bug using a similar device with a horizontal chain of observers, but I couldn't find a configuration that evoked it. I conclude that the bug depends on propagating the pulse upward.
I wanted to know which was faster an observer clock or a row of repeaters set at one tic. I set it up with 14 observers where the first would power a restone line for the repeaters and it would then be detected by the other 13 with the last one sending it's signal into a block with a redstone torch on the top and a line of redstone dust going from that block all the way back to the first observer.
I suspected that both would be the same in time and I was right but then I could add one dispenser but as soon as I put a second one everything started to go bad... The redtone signal got corrupted for some reason and it just started to go wild.
Cleaning up old tickets: This ticket has not been updated recently (~1 year+) so is being closed as Cannot Reproduce. If you feel this is still a valid issue then please comment, or create a new ticket following the Issue Guidelines.
Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki
18 months ago I noticed a similar effect: redstone lamps adjacent to the droppers in a droppervator (item elevator) changed the locations at which stuck items occurred. At the time, an issue report describing stuck items as a bug was closed as "Works as Intended", so I didn't report it. But it feels like it should be related to this issue, so a fix for this could actually fix other issues that are hidden behind the "works as intended" random redstone ticking order. (That's the problem with "intentional" random behavior: Even if it is bugged, nobody can prove it.)