-
Bug
-
Resolution: Invalid
-
None
-
Minecraft 1.12.2
-
Java: Version 8, Update 151 (build 1.8.0_151-b12), Oracle
PC: 64-bit operating system
-
Unconfirmed
-
Survival
[UPDATE: It's an inconsistent behavior with tripwires not detecting high velocity entities that caused this problem, not comparators]
I have built Tango Tek's Iron Phoenix on my multiplayer survival server. I decided to add a golem detection system so that if it detects a suboptimal rate of golem spawning, it will automatically reset itself.
It works by keeping a pulse extender alive everytime a golem passes through. The pulse extender has a lifespan of about 30 seconds (Golems in the iron phoenix spawn once about every 5 seconds). It will turn on for the duration of the rebuilding process, and will only trigger the rebuild the iron phoenix if the pulse extender turns off.
One of the features I decided to add to this is a "recent golem counter". If it counts say 5 golems in a row, it will repeatedly keep the pulse extender on if it detects 5 golems in a row but none for the next 5 (30 second cycles) cycles. The golem counter uses Tango Tek's dropper counter in his iron phoenix when pistons are being extended one by one. The modification I made to it is that I put droppers on both sides so that I can control both a count up and a countdown.
However, this feature somehow breaks when golems (or entities) drop through a tripwire hook system from more than 50 blocks above. It works flawlessly when entities drop at low heights such as 5 blocks from the tripwire hook. Sometimes it triggers a countdown when all that's hooked up to the tripwire portion is a countup (the countdown portion is controlled by the pulse extender being almost out of redstone signal strength)
My theory is that a comparator cannot detect an update when an item moves through 2 droppers back and forth. But I do not know the exact cause of the bug, only how to recreate it. I have recreated it on a flat, sandstone only creative world and my multiplayer survival server.