I need help.
I think this is the right place to ask.
I'm trying to send an on signal up in a spiral. This spiral is very long and thus requires the use of them torches that make the circuit longer. I know those torches revert the signal (i.e the first 15 lines of powder send on signal, then 15 send off signal) but I need everything to be on signal.
Therefore I keep placing 2 torches very close to eachother, meaning that it gets double reversed, meaning it keeps sending an on signal.
But now I'm having problems with the signal itself.
The signal stays on, even if there is nothing on the pressure pad.
Also another question, do TNTs REQUIRE on signal or can they also be set off with off signal? if they can be set off with any signal, I can just put torches to lenghten the signal and not worry about signals being sent when I dont want em to.
If you need to know what im building, or want my save file for that just let me know.
You can send single up by stacking torches on top of each other
This method can only send signal up and you will need to spiral if you need to go down.
Okay, I've seen this enough times that I had to speak up. When I optimize circuits, the most important thing to me is to minimize the number of torches in series. Usually this translates to the amount of time between signal input and computed output (whatever it is). So when I see a long string of torches, I think, "that better be delaying the signal on purpose". The best way to send a signal straight up is a 2x2 spiral of redstone. To continue past 15 blocks, you do this: (side view)
(back layer)
[] []
[] []
[] []
[] []
[]
[]
(front layer)
[]
[] []
[] []
[]
[]
[] []
[] []
..and continue the original spiral from there. Of course, if your whole spiral ends up with an odd number of torches, you need to add another at the end to get the original signal, but this uses far fewer torches than the other method.
For anybody who want's doors that cannot be "picked" leave the left side of the doorway open, place door, then fill in the hole. This will make the door swing to the right effectively operating as a reverse door (seen in double doors. These doors need power to be shut so once you power it with your circuit the only way to open it will be to shut off the circuit. This way you cannot simply open doors by placing a torch in front of them or a button on the wall next to them.
Rollback Post to RevisionRollBack
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
Zaishen, I don't understand what is toggling there. I replicated your setup and found that nothing toggles.
Unless I am misunderstanding what you mean by toggle or something. The switch is essentially a toggler, so there's no reason to try to make a system that toggles, but I think it would be cool to have a button toggle.
Rollback Post to RevisionRollBack
The more Swiss cheese you have, the more holes you have.
The more holes you have, the less Swiss cheese you have.
Therefore, the more Swiss cheese you have the less Swiss cheese you have.
That's really clever, and hilarious that it's reliable. Creating a temporary race condition for a tick seems like something that would only work in Minecraft, but I've actually tested this out in Logisim and with the same amount of gate delay it works just fine. I wonder what the tolerance on a physical circuit would be. By the way, you can compress that horizontally by one by eliminating the fourth column and putting dust on top of the block at E5. The circuit is already stacked to two layers because of the timing stuff at the front, so this isn't that big a deal. If you wanted to fold that part under it and make three layers though, I'd probably leave it at 6x7x3 instead of 5x7x4.
This also works as a JK, if people hadn't realized yet. Sending a signal to either of the blocks in the sixth column will place the circuit in a stable state when the clock pulse hits. Sending a signal to both blocks will effectively freeze the current state. If you invert these signals back to input, you'll have the standard JK truth table. Link both sides with an inverter in the middle, and you have a D. So this is probably a universally improved way to handle all types of latches.
"I'm doing science and I'm still alive."
HOLY CRAP I just made a T flip-flop without even realizing! I thought the other flip-flop I posted was small (until we got nekizalb's), and that one used textbook gates. I was just building a toggle here! (The term "T flip-flop" didn't even cross my mind. In fact, it's inaccurate, since there is only one latch.) But delayers don't really exist in standard circuits.
For a while now, I've been toying with building a simulator in Mathematica and just running all permutations of blocks until a "black box" performed to expectations. Of course, I'd not be the first to perform such a search, but the numbers involved make it obvious that the search is only feasible for very simple systems. Still, I know that the optimal solution will very likely not resemble an ECE way of thinking, building up from gates. It will exhibit "gates" which we haven't thought of yet. That's what I want.
Quote from Zaishen »
Accually, i took in his improvement in the fith collom and added one of my own in the pulsar so its even smaller:
I've gotta give you props for this. That is genius! I wish I'd thought of it.
Quote from Corbald »
I can't get it to toggle anything either. Checked and rechecked. Even took a screenshot of my circuit and yours and overlayed them.. no difference.
What, exactly, is it supposed to do? Perhaps we have expectations that don't represent the proper function?
Draw the picture above in the sim. Then, put a door just to the left of [1,3] (the t-intersection wire). Then press the button. The door should open. Press the button again. The door will close. (Or vice-versa.) Each time you press the button, that section of wire will toggle from on to off and back again.
That's really clever, and hilarious that it's reliable. Creating a temporary race condition for a tick seems like something that would only work in Minecraft, but I've actually tested this out in Logisim and with the same amount of gate delay it works just fine. I wonder what the tolerance on a physical circuit would be. By the way, you can compress that horizontally by one by eliminating the fourth column and putting dust on top of the block at E5. The circuit is already stacked to two layers because of the timing stuff at the front, so this isn't that big a deal. If you wanted to fold that part under it and make three layers though, I'd probably leave it at 6x7x3 instead of 5x7x4.
This also works as a JK, if people hadn't realized yet. Sending a signal to either of the blocks in the sixth column will place the circuit in a stable state when the clock pulse hits. Sending a signal to both blocks will effectively freeze the current state. If you invert these signals back to input, you'll have the standard JK truth table. Link both sides with an inverter in the middle, and you have a D. So this is probably a universally improved way to handle all types of latches.
Hm, I don't know if a better D-Latch has been proposed, or if I have already said this or not (>_<), but here's my pretty small D-Latch. I'm not the best at doing multi-layer circuits, so this is flat, with one exception. It's just, the D-Latches I've seen so far are either too large (10x10x4) and/or non-functional... Plus, I did this from scratch, without basing it off of other people's work...SO GIVE ME CREDIT >_>
First, here's an in-game view; there's a diagram below, too:
The JK flip flop is wrong. If you get an input of 11, it races (which you openly admit on the wiki). This is not the characteristic of a JK Flip Flop. It needs the clock input to achieve the correct truth table. It's basically an overly complex RS Nor Latch.
Technically, the T flip flop is labeled incorrectly as well. The way that it's designed, there isn't an actual T input, only a clock input. T is just built into the circuit as a static 1 so it toggles every single time the clock (which you have labeled as T) pulses. I suppose one could argue that it isn't a T flip flop without the T input, but it toggles and that's what most people need it for. But there is no way (built into the pictured circuit) to disable toggling on clock pulse, which is what a 0 on T does.
So, I've tried it, but I'm not exactly sure if I did my D-Latch right. Can anybody give me feedback? I'm using with a 5-Clock, and it seems to be doing the opposite of what a D-Latch should be doing. Maybe I just don't understand. So yeah, could someone try it out? If necessary, I'll post better screenshots.
I think you're right. Damn..
I have been trying to make a clocked JK for a while now. I failed.. I almost got it but I just can't avoid it racing(I made it update the state only when the clock ticks though).
The first to make a clocked JK, T or/and D Flip-Flop wins a cookie!
Edti: There is a bug in the simulator. Sometimes it bugs the RS Latch in the flip flop. It races when it shouldn't. This doesn't happen in the game.
Specify. What RS Latch? What flip-flop? Note that I discovered a while ago, and posted either here or on my MCRedSim, that a 1-tick pulse will cause RS latches to flash; this will usually propagate across the system. (I call this "cascade failure".) The solution is usually to dismantle latches and other closed loops of torches (clocks). Post a circuit or something, and if possible, narrow down the discrepancy.
An unclocked T latch will essentially toggle infinitly back and forth as long as T is high in no predictable manner. Output is unconfirmable.
The T flip flop on the wiki IS clocked. As I said before, the line you have labeled as T is actually the clock and there isn't a T input anywhere. It's just designed to always toggle when the clock goes high.
Technically, no. An unclocked flip flop is actually called a latch, where as clocking a latch makes it a flip flop. T and JK latches are relatively useless with their toggle functions as they just launch into race conditions. Clocking them prevents the racing and allows them to function in a predictable manner (namely controlling the race).
For the D latch, imagine you're trying to send a signal from one component to another. Component 1 sends out a 1 to go to component 2, but say component 2 isn't ready for it. You can put a D latch between them, and have component 2 hit the enable line on the latch when it's ready for the input from 1. Alternativly, you could have something completely different hit the enable on the latch.
This is what I meant about converting the posted T into a JK before. The "T" input on that is a clock, you see, not the T input. By wiring another input into the blocks in the actual latch, you can control how the clock pulse is applied and make a JK. Simply short those wires together with a bridge to make it a T.
*image*
"You can have my breadboard when you pry it from my cold dead fingers."
Have you successfully constructed this in game? It works great in the simulator, but I can't get success in game. Ironically, mine doesn't work in the simulator at all. Entire right half gets caught in a rapidly pulsing mess.
Quote from Samonite »
You just won a cookie!! (can't that be compressed a bit though?)
Which I just ate sry...
And for the record cookie boy (I mean nothing harmful by this), mine has a smaller footprint than this =P
Just taller >.>
Quote from Samonite »
Still doesn't understand the D though.. Sending a signal to enable the D is exactly the same as sending a signal to a clock input in a D?
I guess you could think of it this way. The main thing behind what he's doing is that it isn't hooked up to autonomous clock that runs regardless. It's a conditional thing *shrug*. A Conditional clock!
Edti: There is a bug in the simulator. Sometimes it bugs the RS Latch in the flip flop. It races when it shouldn't. This doesn't happen in the game.
Specify. What RS Latch? What flip-flop? Note that I discovered a while ago, and posted either here or on my MCRedSim, that a 1-tick pulse will cause RS latches to flash; this will usually propagate across the system. (I call this "cascade failure".) The solution is usually to dismantle latches and other closed loops of torches (clocks). Post a circuit or something, and if possible, narrow down the discrepancy.
I posted a picture of a circuit which will course the bug to happen in the simulator tread.
The bug happens when both inputs in a RS NOR Latch is ON. (the forbidden state)
[*:9u1o5413]In the simulator is starts racing.
[*:9u1o5413]In the game both outputs are OFF.
I'd like to draw the community's attention to this, as this is unknown, and potentially exploitable behavior. I would actually have described the bug thusly:
When both inputs are on in an RS NOR latch (in MC and sim), both outputs are off.
When inputs are in other legal states, both simulators behave appropriately.
When both inputs are brought from on to off SIMULTANEOUSLY:
[*:9u1o5413]In the simulator it starts racing.
[*:9u1o5413]In the game one output will turn on, the choice of which is deterministic and likely follows from relative location (orientation of the circuit relative to global axes).
This represents, not a failure of my program to characterize known behavior, but a hitherto-unknown (or at least unmentioned) fact of redstone behavior. More testing on this can be found at MCRedSim's thread. Potential applications:
[*:9u1o5413]Faster gates
[*:9u1o5413]Instant telegraphs (e.g. East-to-West, but not West-to-East)
[*:9u1o5413]New gates which can use this to save space?
All designs exploiting this behavior, though, will inherently be direction-sensitive. That is to say, all executions of a design like this must point the same direction. It may also possibly need chunk boundaries to land on certain points.
Edit: On a different note, I have designed two very small versions of the 5-clock, one 5x3x2 and one 5x2x3 (3 tall). The 3-tall version uses only 4 redstone (and 5 torches, of course). The other uses 6 redstone. This is as compared to the wiki version, which uses 6 redstone and is 7x3x1.
I'm floored at the amount of detail that flies around in what I've read of this thread so far. Things that I never would've thought to try in Minecraft just work, and you guys all explain how.
Anyway - I have a far less complicated question to ask the experts here. I'm trying to wire up an AND gate to control a set of double doors. I'm using the AND gate because I can easily lock the doors either from the inside or outside depending on which way I'm heading (both switches must be down for the door to open). Yeah, I realize that mobs can't use doors or buttons, but this just feels more secure.
My problem is that while I've gotten it to work great with a single door, I can't get two to flip open at the same time without placing a redstone torch directly above the far door, and it just looks bad to my eyes. Images below of how my circuit works (the basics anyway, showing the on/off state of the circuit - both switches are wired exactly the same, BTW):
(right click - view to see the full images obviously)
Anybody have any suggestions as to how I can rewire this to not have to use the torch above the second door? For whatever reason, a straight line of redstone causes the doors to operate in a flip-flop fashion (where one is always open and the other closed). Thanks in advance.
I'm floored at the amount of detail that flies around in what I've read of this thread so far. Things that I never would've thought to try in Minecraft just work, and you guys all explain how.
Anyway - I have a far less complicated question to ask the experts here. I'm trying to wire up an AND gate to control a set of double doors. I'm using the AND gate because I can easily lock the doors either from the inside or outside depending on which way I'm heading (both switches must be down for the door to open). Yeah, I realize that mobs can't use doors or buttons, but this just feels more secure.
My problem is that while I've gotten it to work great with a single door, I can't get two to flip open at the same time without placing a redstone torch directly above the far door, and it just looks bad to my eyes. Images below of how my circuit works (the basics anyway, showing the on/off state of the circuit - both switches are wired exactly the same, BTW):
-snip-
(right click - view to see the full images obviously)
Anybody have any suggestions as to how I can rewire this to not have to use the torch above the second door? For whatever reason, a straight line of redstone causes the doors to operate in a flip-flop fashion (where one is always open and the other closed). Thanks in advance.
It's hard to tell exactly how discreet you want to be since the whole circuit is open (although I'm sure it's for demonstration purposes), but there are a couple ways of hiding circuits completely in walls so they don't show at all. The usual way is to put the circuitry below the doors. Example:
Placing torches at the indicated locations makes them completely invisible, but they will still activate the doors. Just make your wires run into the blocks those torches are attached to, and add an extra torch (hidden underground, of course) in your wiring for one side to achieve what you are aiming for now with that exposed torch.
Okay, so I've just read through the second half of this thread (sort of figured the first half wouldn't do much good to me), and I guess I'd like to join in on this stuff. I'm planning on making a 4-bit adder-subtractor next, but I can tell I've already been outdone thousands of times over before I even started...
So let's see... the only two big things I've done so far are an 8-bit lock (256 possible inputs) and a 10-digit lock (10^10 possible inputs) with buttons. I've basically been copying real-life schematics and already-posted gates and latches into Minecraft, so I bet I'm pretty far from optimised designs... but I really want to learn how to make more stuff with Redstone and maybe help out if I can.
I independently figured out how to make a T latch, a D flip-flop, and what I think is some kind of a shift register (the output looks like a "straight ring counter" but without the loopback into the input). They're all much bigger and probably have a larger delay than the ones already posted here though. When I read through, I was surprised that what I called a "pulse converter" (A AND A''') seemed to be the correct thing to do for some latches.
I've never taken any classes about these things, and I'm planning on majoring in Electrical Engineering in college, so I figured I'd get started a bit "early". Basically, I've been teaching myself stuff from various websites and putting together things in the game, since I don't know where else I can experiment with this sort of stuff and still see satisfying results. I figured that, while it doesn't act like electricity, the large-scale structures have similar constructions. This seems like a weird place to start, but I guess anywhere else people just wouldn't care about what I make...
Okay, I've seen this enough times that I had to speak up. When I optimize circuits, the most important thing to me is to minimize the number of torches in series. Usually this translates to the amount of time between signal input and computed output (whatever it is). So when I see a long string of torches, I think, "that better be delaying the signal on purpose". The best way to send a signal straight up is a 2x2 spiral of redstone. To continue past 15 blocks, you do this: (side view)
(back layer)
[] []
[] []
[] []
[] []
[]
[]
(front layer)
[]
[] []
[] []
[]
[]
[] []
[] []
..and continue the original spiral from there. Of course, if your whole spiral ends up with an odd number of torches, you need to add another at the end to get the original signal, but this uses far fewer torches than the other method.
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
Oh is the wiki going to get 4clocks and toggles now?
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
Unless I am misunderstanding what you mean by toggle or something. The switch is essentially a toggler, so there's no reason to try to make a system that toggles, but I think it would be cool to have a button toggle.
The more holes you have, the less Swiss cheese you have.
Therefore, the more Swiss cheese you have the less Swiss cheese you have.
What, exactly, is it supposed to do? Perhaps we have expectations that don't represent the proper function?
'Elmer Fudd Blues' Still tragically lethal.
HOLY CRAP I just made a T flip-flop without even realizing! I thought the other flip-flop I posted was small (until we got nekizalb's), and that one used textbook gates. I was just building a toggle here! (The term "T flip-flop" didn't even cross my mind. In fact, it's inaccurate, since there is only one latch.) But delayers don't really exist in standard circuits.
For a while now, I've been toying with building a simulator in Mathematica and just running all permutations of blocks until a "black box" performed to expectations. Of course, I'd not be the first to perform such a search, but the numbers involved make it obvious that the search is only feasible for very simple systems. Still, I know that the optimal solution will very likely not resemble an ECE way of thinking, building up from gates. It will exhibit "gates" which we haven't thought of yet. That's what I want.
I've gotta give you props for this. That is genius! I wish I'd thought of it.
Draw the picture above in the sim. Then, put a door just to the left of [1,3] (the t-intersection wire). Then press the button. The door should open. Press the button again. The door will close. (Or vice-versa.) Each time you press the button, that section of wire will toggle from on to off and back again.
Logisim FTW.
First, here's an in-game view; there's a diagram below, too:
Now, the diagram:
[] [] [] []
[] [] [] [] [] [] []
[] [] []
[] []
[] [] []
[] [] [] [] []
[] [] [] [] [] []
Okay, now for the key:
Goldore: /Q
Coalore: Q
Brown Mushroom/Portabella: Clock input
Obsidian: D input
And, of course:
TNT: Wire
Grass: any block
Torch: Redstone Torch (derp)
White: Air (also, derp)
Now for the more complicated ones:
Side view of all bookcases:
Easy stuff. Side view of crafting table:
[] []
[] []
[] [] []
[]
Looks complicated, but it's basically just a bridge.
Major in charge of the 3rd Battalion of the RMM
The JK flip flop is wrong. If you get an input of 11, it races (which you openly admit on the wiki). This is not the characteristic of a JK Flip Flop. It needs the clock input to achieve the correct truth table. It's basically an overly complex RS Nor Latch.
Technically, the T flip flop is labeled incorrectly as well. The way that it's designed, there isn't an actual T input, only a clock input. T is just built into the circuit as a static 1 so it toggles every single time the clock (which you have labeled as T) pulses. I suppose one could argue that it isn't a T flip flop without the T input, but it toggles and that's what most people need it for. But there is no way (built into the pictured circuit) to disable toggling on clock pulse, which is what a 0 on T does.
Major in charge of the 3rd Battalion of the RMM
Page 23
http://www.minecraftforum.net/viewtopic.php?f=35&t=16440&start=660#p323696
/demand cookie
Hook J and K together for a T, leave K alone and only use J for a D.
Report it over here
Ahm, I understand now. Yeah, I guess you're right, Wervyn.
Major in charge of the 3rd Battalion of the RMM
Specify. What RS Latch? What flip-flop? Note that I discovered a while ago, and posted either here or on my MCRedSim, that a 1-tick pulse will cause RS latches to flash; this will usually propagate across the system. (I call this "cascade failure".) The solution is usually to dismantle latches and other closed loops of torches (clocks). Post a circuit or something, and if possible, narrow down the discrepancy.
The T flip flop on the wiki IS clocked. As I said before, the line you have labeled as T is actually the clock and there isn't a T input anywhere. It's just designed to always toggle when the clock goes high.
Technically, no. An unclocked flip flop is actually called a latch, where as clocking a latch makes it a flip flop. T and JK latches are relatively useless with their toggle functions as they just launch into race conditions. Clocking them prevents the racing and allows them to function in a predictable manner (namely controlling the race).
For the D latch, imagine you're trying to send a signal from one component to another. Component 1 sends out a 1 to go to component 2, but say component 2 isn't ready for it. You can put a D latch between them, and have component 2 hit the enable line on the latch when it's ready for the input from 1. Alternativly, you could have something completely different hit the enable on the latch.
Have you successfully constructed this in game? It works great in the simulator, but I can't get success in game. Ironically, mine doesn't work in the simulator at all. Entire right half gets caught in a rapidly pulsing mess.
And for the record cookie boy (I mean nothing harmful by this), mine has a smaller footprint than this =P
Just taller >.>
I guess you could think of it this way. The main thing behind what he's doing is that it isn't hooked up to autonomous clock that runs regardless. It's a conditional thing *shrug*. A Conditional clock!
I'd like to draw the community's attention to this, as this is unknown, and potentially exploitable behavior. I would actually have described the bug thusly:
When both inputs are on in an RS NOR latch (in MC and sim), both outputs are off.
When inputs are in other legal states, both simulators behave appropriately.
When both inputs are brought from on to off SIMULTANEOUSLY:
[*:9u1o5413]In the simulator it starts racing.
[*:9u1o5413]In the game one output will turn on, the choice of which is deterministic and likely follows from relative location (orientation of the circuit relative to global axes).
This represents, not a failure of my program to characterize known behavior, but a hitherto-unknown (or at least unmentioned) fact of redstone behavior. More testing on this can be found at MCRedSim's thread. Potential applications:
[*:9u1o5413]Faster gates
All designs exploiting this behavior, though, will inherently be direction-sensitive. That is to say, all executions of a design like this must point the same direction. It may also possibly need chunk boundaries to land on certain points.[*:9u1o5413]Instant telegraphs (e.g. East-to-West, but not West-to-East)
[*:9u1o5413]New gates which can use this to save space?
Edit: On a different note, I have designed two very small versions of the 5-clock, one 5x3x2 and one 5x2x3 (3 tall). The 3-tall version uses only 4 redstone (and 5 torches, of course). The other uses 6 redstone. This is as compared to the wiki version, which uses 6 redstone and is 7x3x1.
Anyway - I have a far less complicated question to ask the experts here. I'm trying to wire up an AND gate to control a set of double doors. I'm using the AND gate because I can easily lock the doors either from the inside or outside depending on which way I'm heading (both switches must be down for the door to open). Yeah, I realize that mobs can't use doors or buttons, but this just feels more secure.
My problem is that while I've gotten it to work great with a single door, I can't get two to flip open at the same time without placing a redstone torch directly above the far door, and it just looks bad to my eyes. Images below of how my circuit works (the basics anyway, showing the on/off state of the circuit - both switches are wired exactly the same, BTW):
(right click - view to see the full images obviously)
Anybody have any suggestions as to how I can rewire this to not have to use the torch above the second door? For whatever reason, a straight line of redstone causes the doors to operate in a flip-flop fashion (where one is always open and the other closed). Thanks in advance.
It's hard to tell exactly how discreet you want to be since the whole circuit is open (although I'm sure it's for demonstration purposes), but there are a couple ways of hiding circuits completely in walls so they don't show at all. The usual way is to put the circuitry below the doors. Example:
Placing torches at the indicated locations makes them completely invisible, but they will still activate the doors. Just make your wires run into the blocks those torches are attached to, and add an extra torch (hidden underground, of course) in your wiring for one side to achieve what you are aiming for now with that exposed torch.
'Elmer Fudd Blues' Still tragically lethal.
So let's see... the only two big things I've done so far are an 8-bit lock (256 possible inputs) and a 10-digit lock (10^10 possible inputs) with buttons. I've basically been copying real-life schematics and already-posted gates and latches into Minecraft, so I bet I'm pretty far from optimised designs... but I really want to learn how to make more stuff with Redstone and maybe help out if I can.
I independently figured out how to make a T latch, a D flip-flop, and what I think is some kind of a shift register (the output looks like a "straight ring counter" but without the loopback into the input). They're all much bigger and probably have a larger delay than the ones already posted here though. When I read through, I was surprised that what I called a "pulse converter" (A AND A''') seemed to be the correct thing to do for some latches.
I've never taken any classes about these things, and I'm planning on majoring in Electrical Engineering in college, so I figured I'd get started a bit "early". Basically, I've been teaching myself stuff from various websites and putting together things in the game, since I don't know where else I can experiment with this sort of stuff and still see satisfying results. I figured that, while it doesn't act like electricity, the large-scale structures have similar constructions. This seems like a weird place to start, but I guess anywhere else people just wouldn't care about what I make...