How odd. What I think has happened is that .jar files are set to open with Windows Installer (which it has no business doing). Try right-clicking on the jar file, go to "Open With > Choose default program..." or "Open With..." (depending on your OS), then select Java in the big box if it is available (or press Browse... and select "C:\Program Files\Java\<pick a folder>\bin\java.exe" if it's not available), make sure the "Always use this program..." checkbox is checked, then press OK. If done right, it should open as normal, and will also open properly on double-click now.
@ZisumsHero and Toi333: great work. Stop making me update the wiki! :wink.gif:
Quote from dino »
I'm new to the whole logic gates and player around a bit by lighting a long bridge with blinking lights (one not-gate after another). works like a charm as long as I see the clock generator. the bridge itself is very long, I can't see the other end. so when I'm standing at the far end (clock generator is at the other end) the lights do not blink. when I walk down the bridge starting from the clock generator side, the whole bridge blinks as it 's supposed to do. :smile.gif: is that behavior normal?
I'm afraid so. When you get past ~300 blocks from your circuit, it stops functioning, as it is on an unloaded chunk. (I don't think this is a rigid circle, though, since that would be pretty wasteful of resources. Probably, it holds on to chunks you've been to for 300 blocks, but loads less, which means that if you walked in a straight line, ~300 blocks are loaded behind you and ~200 or less are loaded in front of you.) For your case, you could fix this by having a clock generator at both ends, since you will have to be near at least one of them if you can see the bridge lights.
To make a multiple-bit adder, you wire the C_in of each to the C_out of the previous (lower valued) module, and use the various A's and B's as the inputs (the bits of input A go into each of the A inputs of the bit-adders, with the low bit into the first adder, etc.), and the S's as the bits of the output.
Not sure what you mean by having the doubles down. If you are just multiplying numbers by two, that's a bit shift operation, which is as easy as sending each value of the input to the next higher one in the output (a 0-tick operation).
EDIT: On the optimization front, I have found a 2-tick expression for C_out in this adder (which is the most important factor in improving overall performance of carry adders, since the C_in -> C_out operations pile up for each bit). The expression is C_out = Nor[Nor[a,b], Nor[a,c], Nor[b,c]]. I know that the S output is a 3-tick operation, but I don't think it is very pretty. (The pictured expression is 4 ticks (if you use the 2-tick XOR), so it's probably not worth the space increase.)
Step 1: Get a T Flip-flop from the Redstone circuits page on the wiki. Pick one, it doesn't matter which.
Step 2: Make 5 of them, and connect the T input of each to the Q output of the previous.
Step 3: Connect the button input to the T input of the first one.
The successive Q outputs are the bits of the answer, with the low-order bit being closest to the button.
If you use a lever instead of a button, you can have the lever itself be a sixth low bit.
The update you've all been waiting for (even if you didn't know it yet) is finally here! The biggest change you'll notice is that the UI has been completely overhauled to use standard windowing system elements (toolbar, status bar, menu) in place of the ugly bank of buttons from before. I even got to make a bunch of cute icons to go with it!
New features:
[*:bk49j813]Fixed pressure plate behavior so that it now acts like a switch while paused. Fixed minor pressure plate bugs. [*:bk49j813]Added "ground level" information, now shown by the color of the layer number; expansion buttons use this to keep the ground level, regardless of the order of button pressing.
[*:bk49j813]Added "Zoom In" and "Zoom Out" buttons.
[*:bk49j813]Added Look & Feel adjustment settings.
[*:bk49j813]Adjusted tooltip movement and partially fixed tooltip disappearing bug.
[*:bk49j813]Added XYZ tracking to status bar.
[*:bk49j813]Added opened file and modification tracking.
I figured the dev version was getting too feature-heavy so I released it now so that people wouldn't have to wait any longer, but those requested features are still in the pipeline.
Quote from codewarrior »
That water behavior is hilarious. You can make a curtain of water from a single spring block if you build it right.
Just realized you can make an orthogonal curtain of water by making a 1-wide staircase and putting the spring at the top.
may i suggest adding tracks to it? so we can experiment with making track systems
The thing is, tracks aren't very interactive or complex enough to warrant a simulator. The only redstone-related track fact is with switching T-intersections. Unless you want me to simulate minecarts? If so, I think a separate sim would be warranted.
Quote from codewarrior »
Fences are magic. They have no data at all. It looks like the game figures out which fence sections are connected at load time, which helps to explain why they keep disappearing!
You want a new feature? Use signs to mark points of note in the schematics and show them as a grid cell with a letter in it. You'll probably have to work on preserving all those entities first. You could have a loose format for the sign text, i.e. recognize a sign whose first non-empty line starts with a letter and a colon, then display the letter in the grid cell and the full text in a mouseover.
This feature may have to wait a bit, as I am gearing up to release v2.0. (That's why I haven't posted here in a while.) First thing would be to retain TileEntities internally so that signs (and other entities) aren't destroyed. (After I do that, your cow-based RNG will be able to survive the conversion.) Could you give me a list of possible TileEntities and their formats? (Or better yet, post it to the wiki, or point me to the wiki page.)
Hey guys, I saw this really cool redstone wiring setup for some guy's minecart station, but I was having trouble replicating his results, so I thought I'd see if you guys could show me how to build it. It seems really simple, but I can't get it to work (Although that may be because I tried to modify it a little... X_X) Basically, there are three buttons, two outputs, and two torches. If you press the first button, the torch above the first button turns on and stays on, and output one turns on and stays on. If torch two or output two were on, they are turned off. If you press the second button, the torch above the second button (torch two) turns on and stays on, along with output 2. If output one or torch one were on, they are turned off. If you press button three, all buttons and torches turn off. Sorry if that's a little complicated.
It sounds to me that the torches and the outputs are the same thing. Just put a wire next to the torch if you need the output for something else. The wiring is a little tricky on this one, so it is 4 levels high. Anyway, here it is:
The middle button turns off both torches. The left button turns on the left torch, and the right button turns on the right torch. The outputs are on the bottom corners.
Thanks! Just one question: does it start from the bottom or top? It's kinda hard to tell with it constantly toggling. D:
Press stop in your browser or the ESC button to make the GIF stop animating, and refresh to restart it. The frame where everything is yellow is the lower one (as everything is "block" at that level).
Quote from AlmtyBob »
Thanks for your help guys. I haven't tried those 2 new ideas yet as I spent a while tonight messing with it and ended up with this using a RS NOR and an Implies gate:
-snip-
The basic idea is this:
Cart arrives at the station and stops on a stone pressure plate. The cart will sit there until the rider exits at which point a booster is released from its holding area and comes along to boost the now-empty arrival cart back to the station's main cart holding area. The main cart will round a corner up ahead and trigger a wooden plate inside the corner causing the circuit to reset. Or instead, the booster cart be the one triggering the wooden plate inside the corner. Thanks to ssssssgr on YouTube for the wait-for-exit idea.
I'll probably try a few designs, clean it up, then post it on the MTA thread unless someone beats me to it.
I think your design is basically the same as grootie's, except he uses the smaller IMPLIES design. As I said, the difference with mine is that it doesn't turn the output off again if you step on the pressure plate twice. If it doesn't matter, than go with whatever works best with your space considerations.
Are you saying that a pressure plate will come back up if you exit a minecart, even if the minecart is still sitting on it? This is surprising information. Also, I thought that minecarts grind to a halt if they hit pressure plates (or anything else, for that matter). How do you do it without losing momentum?
I spent last night trying to work out a latch and I'm stumped. Here's my desired outcome:
I have one torch, a pressure plate, and a button. The torch is currently off. I walk onto the pressure plate and stay there. Torch is still off. I step off the plate. The torch turns on. I press the button to reset the system and the torch tuns off. Repeat.
Basically I need to wire pressure plate such that it will only change the torch's state once I've stepped onto and then off of the pressure plate. Does that make sense? How can I do this?
Since you need it to hold its state, you need an RS NOR. Since you have particular triggers for turning the torch on and off, you just wire them to the R and S inputs. And since you need a trigger based on a state change, you need an edge detector (of the on->off variety). Putting it all together:
The square on the left is the pressure plate, the switch in the bottom right corner is the reset button. The output is the right-most torch. This doesn't have Trism's problem with retriggering.
Quote from nephewjack »
Hey guys, I saw this really cool redstone wiring setup for some guy's minecart station, but I was having trouble replicating his results, so I thought I'd see if you guys could show me how to build it. It seems really simple, but I can't get it to work (Although that may be because I tried to modify it a little... X_X) Basically, there are three buttons, two outputs, and two torches. If you press the first button, the torch above the first button turns on and stays on, and output one turns on and stays on. If torch two or output two were on, they are turned off. If you press the second button, the torch above the second button (torch two) turns on and stays on, along with output 2. If output one or torch one were on, they are turned off. If you press button three, all buttons and torches turn off. Sorry if that's a little complicated.
It sounds to me that the torches and the outputs are the same thing. Just put a wire next to the torch if you need the output for something else. The wiring is a little tricky on this one, so it is 4 levels high. Anyway, here it is:
The middle button turns off both torches. The left button turns on the left torch, and the right button turns on the right torch. The outputs are on the bottom corners.
You save 29% dust, but add 466% time to complete. As far as trade-offs go, that's a pretty rotten deal.
Quote from grootie »
I currently working on an automated minecart station and im wondering if someone could help me with the following gate:
I1 I2 O1 O2
0 0 0 0
0 1 0 1
1 0 1 0
1 1 x 0
The x does not really matter, as its only used to set I2 to 1 when O1 is 1.
Edit: I just found out that i need a A is not implied by B gate, although i have no clue on how to make it in minecraft..
Edit2: Found it :smile.gif: I used a RS NOR latch and an OR gate..
You shouldn't need an RS NOR unless you are storing data. If you aren't, it's just a simple gate. As you point out, it is the B NOT IMPLIES A gate. A simple design for that:
What throws me off is that the plates trigger on mouseover, so when I place them while paused, I have no choice but to have them on. I can't click them off like a button because that removes them.
(btw, I updated the data values here. Feel free to check your notes against them.)
I see your point. I've made it so that they behave like buttons when paused, and as they do now while playing. I also fixed that bug when leaving the field (where the last selected plate would stay on indefinitely). Will release soon, but I would like to bundle a feature with it. Got any ideas?
Nice work with the data values. It was looking a little dated. What about fences, though? Have they no data? (Haven't messed with them myself.)
Progress on my computer. 4 bits, but will be extendable. ALU with ADD, AND, OR and XOR operations etc.
In the picture, the ALU is only 2 bits high, and there is no instruction decoding unit.
I think I can get it to work, but it will be very slow. it will have very simple instructions, wich will each take approx. 15 seconds each. The databus and towers* that carry the control signals take a long time to get to end, so each clock-tick will have to be about 3 seconds. -snip-
* Tower( Block, Lit torch, dark torch, redstone): <- Line in
BTW: Thanks to nekizalb for suggesting to do this outside, Orels I would have had to dig a big hole!
We should spend some time making a minimal ALU. Everyone here seems to dislike demultiplexers, though, so maybe we could make one without it (like this one, if I understand correctly). I will say, though, that I still strongly dislike those torch-towers, as removing them is one of the easiest ways to improve response time in circuits.
Quote from Alanim »
curious, would it be possible to make a RNG through redstone? and how big would you assume it'd be?
To do it with traditional logic gates would be pretty big, but somone already found a better way. There may be some correlation with those outputs, though, so you may have to work with it a bit. You also don't know when outputs will come. I don't know whether this is faster or more reliable than a real RNG, which would certainly take many many ticks to complete, considering its complexity.
Quote from Shroomer »
WTF my clocks keep burning out goddamnit D:< is there any way to prevent this?
EDIT: everything is burning out D8<<<
This happened to me once. Restart Minecraft (not just to the title screen) and things should go back to normal.
EDIT: I've been thinking about water circuits lately, and a few people have said in this regard that water circuits are old stuff and not worth pursuing anymore, now that we have something better. I say, no, this isn't the case. water/torch/sand circuits involve actual block movement, which means we can close hallways, drop bridges, and all sorts of other cool things which can't be done with redstone circuits (which are currently limited to torches and doors). So, the question becomes, how do we interface these two fundamentally different types of circuits?
Water -> Redstone seems easy enough. Controlled water can be made to knock over torches or wash off redstone dust, or if you don't want to lose the redstone, you can activate a switch and have that get knocked out. Falling sand does the equivalent to anything attached to or on top of it.
Redstone -> Water is much harder, though. One thing which I recently thought of is glitched sand, which will fall if any redstone adjacent to it is made to change state. This, obviously, requires hacking, though, so is not an optimal solution. Another option is TNT. Although annoyingly destructive when dry, it can be made not to destroy anything if it falls into water. This technique is well known for the purposes of TNT cannons, but they offer other options as well. Activated TNT becomes an entity, and stops being a block, which means anything on top of it (like, say, sand) can be released, which can trigger a water circuit. I'm not sure, but dropping sand on the TNT may make it explode destructively. If so, another option looks like this:
[] [] [] []
Activating the TNT makes it disappear and allows the water to extinguish the torch, thereby dropping the sand while keeping the TNT wet.
EDIT2: here's a schematic (open with MCEdit) for a trap based on a redstone -> water circuit interface. A switch activates TNT, which releases water onto a torch, which then triggers sand to fall around the switch, trapping anyone stupid enough to stand that close to the switch.
When I place a pressure pad it is initially off, but it turns on as soon as I move my mouse pointer one pixel. I remove the pad and place a new one in the same block, and it's always on.
I just hit play, and oh, how cute! My mouse pointer triggers them on mouseover! The one that was just under the cursor doesn't turn off when I mouse outside the grid. I'm not too sure what to think about this behavior, just that the way it works while paused is a bit odd.
It's the same with forever-on buttons. When I first started working on this, I wasn't sure whether to make buttons (and now plates) have timers based on the global clock (so that they can be paused) or to have them work in real-time. I decided on this behavior because otherwise the number of ticks you get from a button depends on how long you spend paused, and that essentially means it is exhibiting behavior unobtainable in MC, which then means that buttons become useless while paused (which I use quite often in order to track logic propagation). In short: considering the pros and cons, I think this makes more sense and is more usable overall than the alternative, although I admit it doesn't immediately make sense when first operating them while paused.
As far as the plates not turning off when mousing out of the grid, I say, stop putting plates at the edges! (Or mousing out really fast.) Maybe I'll look into fixing that for the next version.
Quote from Kamilo »
thanks, now this link is working, i think it is working because there was an update today.
The 1.8 link is still there (now moved to "earlier versions"). Does that one work for you? (Not that I'm recommending 1.8 over 1.82, but I don't want any broken or wonky links.)
I just double-checked, and the link (after the initial mix-up) is working fine. If I had a server to host these, I'd be using it, and not MediaFire, but it's done well so far. And if someone here donated server space to host these, then updates would be even more complicated to keep everything up-to-date. In any case, I've uploaded a new version, but am leaving the old links up, in case you have a problem downloading the latest.
v1.82 fixes a bug I introduced in v1.8 which caused the layer options to break, as well as added an extra option to modify the "generic block" type. I left off non-blocks and blocks which you wouldn't ordinarily be able to put redstone on, but you are warned if you make glitched sand/gravel (which are available) using this tool.
Invalid or Deleted File
The key you provided for file download was invalid. This is usually caused because the file is no longer stored on Mediafire. This occurs when the file is removed by the originating user or Mediafire.
I hope it's because you found an atrocious bug and pulled it.
Oops, sorry about that. Yes, it was because of a bug. Shortly after I posted it, I realized it broke .rdat saves, and would make incompatible ones as well. Tiny fix, not even worth bumping the version for. I guess I got confused with the replacement. Anyway, it's fixed now.
Quote from toi333 »
EDIT: Anyway, why do you want to simulate water in your program?
Well, I know you're relatively new to MC, so I'll give a little history. Back before Alpha, we had Indev and Infdev. There was no redstone back in those days, but people realized you could still do logic using water and sand on torches. (You can see this method in the airlock design.) I started reading a water circuit page recently, and got nostalgic. It fits within the general scope of my program, so why not? Of course nowadays, we have limited water to deal with, rather than the unlimited water (which just expanded every direction but upwards if nothing block-like was in the way).
0
0
0
I'm afraid so. When you get past ~300 blocks from your circuit, it stops functioning, as it is on an unloaded chunk. (I don't think this is a rigid circle, though, since that would be pretty wasteful of resources. Probably, it holds on to chunks you've been to for 300 blocks, but loads less, which means that if you walked in a straight line, ~300 blocks are loaded behind you and ~200 or less are loaded in front of you.) For your case, you could fix this by having a clock generator at both ends, since you will have to be near at least one of them if you can see the bridge lights.
0
To make a multiple-bit adder, you wire the C_in of each to the C_out of the previous (lower valued) module, and use the various A's and B's as the inputs (the bits of input A go into each of the A inputs of the bit-adders, with the low bit into the first adder, etc.), and the S's as the bits of the output.
Not sure what you mean by having the doubles down. If you are just multiplying numbers by two, that's a bit shift operation, which is as easy as sending each value of the input to the next higher one in the output (a 0-tick operation).
EDIT: On the optimization front, I have found a 2-tick expression for C_out in this adder (which is the most important factor in improving overall performance of carry adders, since the C_in -> C_out operations pile up for each bit). The expression is C_out = Nor[Nor[a,b], Nor[a,c], Nor[b,c]]. I know that the S output is a 3-tick operation, but I don't think it is very pretty. (The pictured expression is 4 ticks (if you use the 2-tick XOR), so it's probably not worth the space increase.)
0
How to make a binary counter
Step 1: Get a T Flip-flop from the Redstone circuits page on the wiki. Pick one, it doesn't matter which.
Step 2: Make 5 of them, and connect the T input of each to the Q output of the previous.
Step 3: Connect the button input to the T input of the first one.
The successive Q outputs are the bits of the answer, with the low-order bit being closest to the button.
If you use a lever instead of a button, you can have the lever itself be a sixth low bit.
0
New features:
[*:bk49j813]Fixed pressure plate behavior so that it now acts like a switch while paused. Fixed minor pressure plate bugs. [*:bk49j813]Added "ground level" information, now shown by the color of the layer number; expansion buttons use this to keep the ground level, regardless of the order of button pressing.
[*:bk49j813]Added "Zoom In" and "Zoom Out" buttons.
[*:bk49j813]Added Look & Feel adjustment settings.
[*:bk49j813]Adjusted tooltip movement and partially fixed tooltip disappearing bug.
[*:bk49j813]Added XYZ tracking to status bar.
[*:bk49j813]Added opened file and modification tracking.
I figured the dev version was getting too feature-heavy so I released it now so that people wouldn't have to wait any longer, but those requested features are still in the pipeline.
Just realized you can make an orthogonal curtain of water by making a 1-wide staircase and putting the spring at the top.
0
The thing is, tracks aren't very interactive or complex enough to warrant a simulator. The only redstone-related track fact is with switching T-intersections. Unless you want me to simulate minecarts? If so, I think a separate sim would be warranted.
This feature may have to wait a bit, as I am gearing up to release v2.0. (That's why I haven't posted here in a while.) First thing would be to retain TileEntities internally so that signs (and other entities) aren't destroyed. (After I do that, your cow-based RNG will be able to survive the conversion.) Could you give me a list of possible TileEntities and their formats? (Or better yet, post it to the wiki, or point me to the wiki page.)
0
Press stop in your browser or the ESC button to make the GIF stop animating, and refresh to restart it. The frame where everything is yellow is the lower one (as everything is "block" at that level).
I think your design is basically the same as grootie's, except he uses the smaller IMPLIES design. As I said, the difference with mine is that it doesn't turn the output off again if you step on the pressure plate twice. If it doesn't matter, than go with whatever works best with your space considerations.
Are you saying that a pressure plate will come back up if you exit a minecart, even if the minecart is still sitting on it? This is surprising information. Also, I thought that minecarts grind to a halt if they hit pressure plates (or anything else, for that matter). How do you do it without losing momentum?
0
Since you need it to hold its state, you need an RS NOR. Since you have particular triggers for turning the torch on and off, you just wire them to the R and S inputs. And since you need a trigger based on a state change, you need an edge detector (of the on->off variety). Putting it all together:
The square on the left is the pressure plate, the switch in the bottom right corner is the reset button. The output is the right-most torch. This doesn't have Trism's problem with retriggering.
It sounds to me that the torches and the outputs are the same thing. Just put a wire next to the torch if you need the output for something else. The wiring is a little tricky on this one, so it is 4 levels high. Anyway, here it is:
The middle button turns off both torches. The left button turns on the left torch, and the right button turns on the right torch. The outputs are on the bottom corners.
0
The signal doesn't go 13 blocks, it goes 15. Add a block and a torch and that's 17 blocks per repeating unit. Comparison over 17*3=51 length wire:
[*:3i444wfn]Long wire method: 48 dust, 3 ticks
[*:3i444wfn]Short wire method: 34 dust, 17 ticks
You save 29% dust, but add 466% time to complete. As far as trade-offs go, that's a pretty rotten deal.
You shouldn't need an RS NOR unless you are storing data. If you aren't, it's just a simple gate. As you point out, it is the B NOT IMPLIES A gate. A simple design for that:
.A
[] [] [] [] []
.B
0
I see your point. I've made it so that they behave like buttons when paused, and as they do now while playing. I also fixed that bug when leaving the field (where the last selected plate would stay on indefinitely). Will release soon, but I would like to bundle a feature with it. Got any ideas?
Nice work with the data values. It was looking a little dated. What about fences, though? Have they no data? (Haven't messed with them myself.)
0
We should spend some time making a minimal ALU. Everyone here seems to dislike demultiplexers, though, so maybe we could make one without it (like this one, if I understand correctly). I will say, though, that I still strongly dislike those torch-towers, as removing them is one of the easiest ways to improve response time in circuits.
To do it with traditional logic gates would be pretty big, but somone already found a better way. There may be some correlation with those outputs, though, so you may have to work with it a bit. You also don't know when outputs will come. I don't know whether this is faster or more reliable than a real RNG, which would certainly take many many ticks to complete, considering its complexity.
This happened to me once. Restart Minecraft (not just to the title screen) and things should go back to normal.
EDIT: I've been thinking about water circuits lately, and a few people have said in this regard that water circuits are old stuff and not worth pursuing anymore, now that we have something better. I say, no, this isn't the case. water/torch/sand circuits involve actual block movement, which means we can close hallways, drop bridges, and all sorts of other cool things which can't be done with redstone circuits (which are currently limited to torches and doors). So, the question becomes, how do we interface these two fundamentally different types of circuits?
Water -> Redstone seems easy enough. Controlled water can be made to knock over torches or wash off redstone dust, or if you don't want to lose the redstone, you can activate a switch and have that get knocked out. Falling sand does the equivalent to anything attached to or on top of it.
Redstone -> Water is much harder, though. One thing which I recently thought of is glitched sand, which will fall if any redstone adjacent to it is made to change state. This, obviously, requires hacking, though, so is not an optimal solution. Another option is TNT. Although annoyingly destructive when dry, it can be made not to destroy anything if it falls into water. This technique is well known for the purposes of TNT cannons, but they offer other options as well. Activated TNT becomes an entity, and stops being a block, which means anything on top of it (like, say, sand) can be released, which can trigger a water circuit. I'm not sure, but dropping sand on the TNT may make it explode destructively. If so, another option looks like this:
[] [] []
Activating the TNT makes it disappear and allows the water to extinguish the torch, thereby dropping the sand while keeping the TNT wet.
EDIT2: here's a schematic (open with MCEdit) for a trap based on a redstone -> water circuit interface. A switch activates TNT, which releases water onto a torch, which then triggers sand to fall around the switch, trapping anyone stupid enough to stand that close to the switch.
Sandtrap
0
It's the same with forever-on buttons. When I first started working on this, I wasn't sure whether to make buttons (and now plates) have timers based on the global clock (so that they can be paused) or to have them work in real-time. I decided on this behavior because otherwise the number of ticks you get from a button depends on how long you spend paused, and that essentially means it is exhibiting behavior unobtainable in MC, which then means that buttons become useless while paused (which I use quite often in order to track logic propagation). In short: considering the pros and cons, I think this makes more sense and is more usable overall than the alternative, although I admit it doesn't immediately make sense when first operating them while paused.
As far as the plates not turning off when mousing out of the grid, I say, stop putting plates at the edges! (Or mousing out really fast.) Maybe I'll look into fixing that for the next version.
The 1.8 link is still there (now moved to "earlier versions"). Does that one work for you? (Not that I'm recommending 1.8 over 1.82, but I don't want any broken or wonky links.)
0
I just double-checked, and the link (after the initial mix-up) is working fine. If I had a server to host these, I'd be using it, and not MediaFire, but it's done well so far. And if someone here donated server space to host these, then updates would be even more complicated to keep everything up-to-date. In any case, I've uploaded a new version, but am leaving the old links up, in case you have a problem downloading the latest.
v1.82 fixes a bug I introduced in v1.8 which caused the layer options to break, as well as added an extra option to modify the "generic block" type. I left off non-blocks and blocks which you wouldn't ordinarily be able to put redstone on, but you are warned if you make glitched sand/gravel (which are available) using this tool.
0
Oops, sorry about that. Yes, it was because of a bug. Shortly after I posted it, I realized it broke .rdat saves, and would make incompatible ones as well. Tiny fix, not even worth bumping the version for. I guess I got confused with the replacement. Anyway, it's fixed now.
Well, I know you're relatively new to MC, so I'll give a little history. Back before Alpha, we had Indev and Infdev. There was no redstone back in those days, but people realized you could still do logic using water and sand on torches. (You can see this method in the airlock design.) I started reading a water circuit page recently, and got nostalgic. It fits within the general scope of my program, so why not? Of course nowadays, we have limited water to deal with, rather than the unlimited water (which just expanded every direction but upwards if nothing block-like was in the way).