Map file with demonstration of glitch included in the attachment. Example contraption @ (-173, 4, -21). Bugged dropper is the bottom-right dropper in the 2x2 array of droppers.
Rebuilding the affected dropper or even the entire contraption results in the dropper working as expected for as few as one attempt. After multiple firings, the same dropper becomes "jammed". It is consistently the same dropper. May have to do with processing order or chunk border?
This bug has been cropping up in a number of other contraptions, such as autobrewers and other dropper-dependent contraptions. However, this is one of the only methods I've found that consistently reproduce the bug. It is the same bug every time, the dropper is "jammed" in the triggered:true state, even when no longer powered and then it refuses to be activated again.
Included in Environment are the JVM settings I was running at. However, the default JVM settings also produce this bug.
Additional investigation:
Included contraption glitches like this even when not on chunk boundaries.
If tiled into a 4x2, the glitch repeats and the bottom right and the bottom third from the right dropper becomes jammed consistently, as the original bug. May be coordinate parity related? Inconclusive.
Related issues
Attachments
Comments
migrated
migrated
When will this glitch be looked at? It's an on-going problem with dropper behavior.
tryashtar
This is a consequence of MC-108
migrated
@tryashtar How is this in any way related to quasiconnectivity or intended behavior?
There are NO blocks in the powered state before the button is pushed a second time.
There are NO blocks in the powered state long after the button is released.
Providing power to the affected dropper DOES NOT activate it.
Reopening this unless an explanation as to how the issues are related is given because it DOES NOT look like this was properly investigated.
Arisa Bot
