MC-123912Comparator doesn't update properly in a dropper clock in certain conditions (inconsistent behavior) [UPDATE, it's inconsistent behavior with tripwires, not comparators]
[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.
Environment
Java: Version 8, Update 151 (build 1.8.0_151-b12), Oracle
PC: 64-bit operating system
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Created Issue:
Comparator doesn't update properly in a dropper clock in certain conditions
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.
Environment
Java: Version 8, Update 151 (build 1.8.0_151-b12), Oracle
PC: 64-bit operating system
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
Comparator doesn't update properly in a dropper clock in certain conditions (inconsistent behavior)
Comparator doesn't update properly in a dropper clock in certain conditions (inconsistent behavior) [UPDATE, it's inconsistent behavior with tripwires, 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.
[UPDATE: It's an inconsistent behavior with tripwires 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.
[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.
Can you attach the zipped world folder please? If the file is to big, upload it somewhere else and link to it here.
The file is too big. I've never tried uploading worlds to online storages, but I've tried google drive in this case. Please let me know if it doesn't work and give me a website of preference: https://drive.google.com/file/d/17GTGQBTN0A_zHitIKcluSUvkbJJc7Ghy/view?usp=sharing
The coordinates of the dropper counter is x = -1, y = 106, z = 351.
Your contraption simply does not work.
I have tested it with slow-moving entities and it successfully counts how many entities move though using the signal strength of the redstone that is off.
Both comparators start with a signal strength of 15 from the full droppers.
Every time an entity moves through the tripwire hook, the droppers on the right will move 1 item (64-stackable) back and forth using the 2 tick repeater to ensure the following order: full dropper moves item to empty dropper, empty dropper now has 1 item, the item moves back making the full dropper full again. That will cause the comparator on the right to have a signal strength of 14 momentarily. Since both comparators are on subtract mode, the comparator on the right momentarily has a main input of 15, and a side input of 14, outputting a signal strength of 1. This dropper counter system was showcased in Tango Tek's Iron phoenix video at 8:25: https://youtu.be/kxixJ5P_V7k?t=8m25s. I modified it so that it counts down by one every time the long comparator pulse extender to the right is almost out of signal strength.
You can test this out by moving through the tripwire hook slowly 5 times, or producing 5 long pulses through the redstone dust before the repeater on the right, you should see that the redstone dust on the right will have a signal strength of 5. But any golem that falls down really fast will not trigger this system, and sometimes resets it too.
I am not saying that this does not work at all, I am saying that the behavior is inconsistent when the pulses are really short.