in this video i showcase 2 very usefull Block Update Processor Arrays. these are very usefull to have Bud zones side by side.
The first design is a Dust n Torch Array as seen on roboticaust livestream. one side is the off, one side is the on, power comes from the off side through a not gate (redstone torch on the side of a block) powers the on line until the length of wire is met. then its off, into a repeater and back into the offline and loops: now the trick is the entire offline is not gates leaking into the on line. so the game is seeing it as a length of wire running out of power but if anything near that on line updates, it causes it to see the not gate power and update the line.the line updates, triggers the repeater and sends it back through the offline to shut off the not gates and reset it. There are more outputs on the unit that werent displayed in the video.
The second B.U.Processor is a Minecart Version, powered rails can receive power through the space above them, but don't update properly when powered in this way. Combined with a detector rail and minecart, this can be exploited to make the BUD array below. All of the p-rails in this device act as sensors.
in this video i showcase 2 very usefull Block Update Processor Arrays. these are very usefull to have Bud zones side by side.
The first design is a Dust n Torch Array as seen on roboticaust livestream. one side is the off, one side is the on, power comes from the off side through a not gate (redstone torch on the side of a block) powers the on line until the length of wire is met. then its off, into a repeater and back into the offline and loops: now the trick is the entire offline is not gates leaking into the on line. so the game is seeing it as a length of wire running out of power but if anything near that on line updates, it causes it to see the not gate power and update the line.the line updates, triggers the repeater and sends it back through the offline to shut off the not gates and reset it. There are more outputs on the unit that werent displayed in the video.
The second B.U.Processor is a Minecart Version, powered rails can receive power through the space above them, but don't update properly when powered in this way. Combined with a detector rail and minecart, this can be exploited to make the BUD array below. All of the p-rails in this device act as sensors.
There's actually more types. Buds can be made to detect changes made near detector rails, water, powered rails, pistons, redstone wire and even redstone torches (this last one is actually a glitch and tends to misfire every so often but has a strange property of being able to detect redstone changes made within 2 blocks).
Niice BUD arrays, and great explanation :smile.gif:
But I'm still curious about what counts as an update. Redstone updates can be detected further away by other BUDs too (here's a paper about those piston-based ones) - maybe even more than 2 blocks away. And adding repeaters (same amount to keep the overall timing) can change results too... Please reduce my confusion :wink.gif:
It's honestly the same exact trick. The piston ones work by updating the piston then resetting themselves via a loop in the circuit. That is essentially all these are doing. For example, the redstone wire one works by setting the line via the torch not in the loop so that it always lights up to a specific point in the length of the wire. The other torches come on but don't update the line since the game sees it as an active line already. When any block updates (meaning one block ID for another, damage value changes count too such as wheat growth), then the line gets recalculated and it loops back in on itself via the update. This causes all the torches but the one outside the loop to shut off, along with the line they power and the length of wire is placed back to default.
Some other designs such as the "t-bud" and the detector rail version not shown in this video use a similar piston mechanic that sees the piston as extended when it shouldn't be and sets it back to default, which fires the contraption. The game currently checks this sort of stuff when block IDs change next to other blocks because a lot of other dynamics need these updates to function properly, such as redstone components needing to be updated as levers are flipped into different positions, or water flows fixing themselves when blocks nearby are removed or placed. This is also the cause of such bugs as pressure plates, repeaters and other things that temporarily change IDs becoming frozen when the player quits the world.
All in all, it's the same dynamics, same mechanics and it's just an exploit of the games inner workings and not a bug.
in this video i showcase 2 very usefull Block Update Processor Arrays. these are very usefull to have Bud zones side by side.
The first design is a Dust n Torch Array as seen on roboticaust livestream. one side is the off, one side is the on, power comes from the off side through a not gate (redstone torch on the side of a block) powers the on line until the length of wire is met. then its off, into a repeater and back into the offline and loops: now the trick is the entire offline is not gates leaking into the on line. so the game is seeing it as a length of wire running out of power but if anything near that on line updates, it causes it to see the not gate power and update the line.the line updates, triggers the repeater and sends it back through the offline to shut off the not gates and reset it. There are more outputs on the unit that werent displayed in the video.
The second B.U.Processor is a Minecart Version, powered rails can receive power through the space above them, but don't update properly when powered in this way. Combined with a detector rail and minecart, this can be exploited to make the BUD array below. All of the p-rails in this device act as sensors.
favourite to catch secret livestreams.!
I halp'd
You were given credit.
I'm well aware. Inside jokes between friends ;p
There's actually more types. Buds can be made to detect changes made near detector rails, water, powered rails, pistons, redstone wire and even redstone torches (this last one is actually a glitch and tends to misfire every so often but has a strange property of being able to detect redstone changes made within 2 blocks).
It's honestly the same exact trick. The piston ones work by updating the piston then resetting themselves via a loop in the circuit. That is essentially all these are doing. For example, the redstone wire one works by setting the line via the torch not in the loop so that it always lights up to a specific point in the length of the wire. The other torches come on but don't update the line since the game sees it as an active line already. When any block updates (meaning one block ID for another, damage value changes count too such as wheat growth), then the line gets recalculated and it loops back in on itself via the update. This causes all the torches but the one outside the loop to shut off, along with the line they power and the length of wire is placed back to default.
Some other designs such as the "t-bud" and the detector rail version not shown in this video use a similar piston mechanic that sees the piston as extended when it shouldn't be and sets it back to default, which fires the contraption. The game currently checks this sort of stuff when block IDs change next to other blocks because a lot of other dynamics need these updates to function properly, such as redstone components needing to be updated as levers are flipped into different positions, or water flows fixing themselves when blocks nearby are removed or placed. This is also the cause of such bugs as pressure plates, repeaters and other things that temporarily change IDs becoming frozen when the player quits the world.
All in all, it's the same dynamics, same mechanics and it's just an exploit of the games inner workings and not a bug.