MC-169169After few activations, Dropper gets "jammed" in triggered:true state and won't trigger again.
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.
Environment
Windows 10 Pro 64-bit, Java 1.8.0_51, Intel Core i5-4670K @ 3.40GHz x4, JVM arguments: -Xmx16G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50
Linked Issues
Attachments1
Created Issue:
After few activations, Dropper gets "jammed" in triggered:true state and won't trigger again.
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.
Environment
Windows 10 Pro 64-bit, Java 1.8.0_51, Intel Core i5-4670K @ 3.40GHz x4, JVM arguments: -Xmx16G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50
Attachments1
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.
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.
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
When will this glitch be looked at? It's an on-going problem with dropper behavior.
This is a consequence of
MC-108@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.
Have a look at the Resolution and the comments to see why this ticket has been resolved. If you think this ticket has been resolved erroneously you can contact the Mojira staff on Discord or Reddit.
– I am a bot. This action was performed automatically! Please report any issues on Discord or Reddit