I think by "timer" you mean a circuit which will complete one cycle and then stop and wait for a new activation (some people use "timer" to mean a clock circuit which repeats its cycle indefinitely).
Here's a compact silent two-hopper clock circuit (adapted from a design by TitiSurMinecraft) which can be turned into such a timer by removing one of the torches on the right:
The torches on the left each stay on for half a cycle, and the torches on the right blink every half cycle. I think you might be able to adapt that to your purpose.
(1.8:) Place seven named armor stands in a row. Use an execute @r[type=ArmorStand,name=X] setblock command (with some other arguments) to randomly choose one of the armor stands and place a block of redstone next to it, powering an output. Then use a fill command to set all the possible blocks of redstone back to stone (or something, but not air since that would cause a block light recalculation) to reset the outputs.
Dragnoz has a good video discussing randomizers, including a method similar to this (though he uses falling sand entities instead of setblock which seems unnecessarily complicated):
There's no way to tell if there's exactly 80 items in a hopper, you'd have to count the items as they go in. But you can tell when a hopper reaches 92 items (signal strength 5 from a comparator) then enable it for exactly 32 seconds to allow only 80 items to transfer into the furnace (except that the furnace can only hold 64 items to be smelted at a time, so easiest to use a second hopper between the two to hold the extra 16 items while the first few are being smelted).
I don't do much on servers, so I'm only guessing here, but:
Tripwire hooks have an interesting property that they provide random block updates to their neighbors (and the neighbors of the block they're attached to) about once a minute (when they're updated by the three-updates-per-game-tick-per-chunk-section thing). The tripwire hook doesn't need to be part of a tripwire circuit for this to work, so it can be otherwise redstone-neutral.
If a tripwire hook is next to another redstone component, that block update might force the redstone component to check and update its own status, correcting any glitch.
If you want updates faster than about 1 minute, you can put over a dozen tripwire hooks around a BUD circuit, dropping the average update time to as little as 5 seconds, and have the BUD circuit update your clock (one changing component next to the redstone component which freezes)
convert the binary input to hex, check if the output is 10, if 10, then subtract 10 from it, and carry to the next 4 bit segment.Now you have an analog decimal output, whitch is as good as any decimal representation. … before i forgot, no binary to bcd in the design, it goes with 4 bit binary to 1 digit hexadecimal, and thats going to be traslated into decimal.
Frontrider's first post seems to imply that they don't realize the output 1s digit depends on more than just the four lowest bits of the input. I think they realize that later, and that this approach is only useful for converting from 4-bit binary to analog-coded decimal (ACD?), which is trivial, and not useful for larger binary encodings.
But implementing the double dabble algorithm with comparators might be feasible (first converting from binary to analog-coded hexadecimal). Comparators are good at subtraction (and thus, with a little more effort, at addition). The double dabble algorithm implemented on hexadecimal registers would require left bit shifts (equivalent to multiplying by 2, which is equivalent to adding a value to itself, so comparators could do it) and adding 3 (again, addition). There are additional checks that have to be made between registers and between steps that might cause this to stretch out, but I might play around with it. From experience, I'll guess it will end up being smaller by volume than RedRoboHood's but longer in length and much slower.
…A lot of output modules (example ) depend on BCD input, and can't really use analog input. If you used an analog approach to convert from binary to decimal, you would then need to design your own analog-decimal to 7-segment display decoder (not an easy task by any stretch, if you want to make it fast and compact).
Converting from analog-coded decimal to one-active is pretty easy, and many 7SDs run off of one-active. For example, here's a 3-wide ACD-to-one-hot decoder that could be put under, say, Koala_Steamed's 7SD: .
The green clay is just an input tester, the circuit starts at the lime wool. The hopper produces a signal strength of 11.
For converting from binary to multi-digit decimal, I don't think there's anything better than the double dabble algorithm.
The easiest way to go from BCD to 7SD is to first convert to one-active, then convert that to 7SD. Look up "minecraft 7-segment display" on youtube -- most of them go from one-active to 7SD.
Sorry, no world download, but here's the original thread where Koala and I figured it out which has an extra picture.
The green blocks are just an analog clock to test the circuit, and the pistons are the output -- ignore them. The article is still in my userspace because it's still under construction and I haven't made a better picture yet.
The input is the first gold block on the right where the green blocks connect.
Okay, to convert it to 8-bit binary (though 7-bit would be enough?)…
So the 1s row can be converted easily using an A2B decoder. I have a couple examples on one of my wiki pages, depending on whether you're designing for speed or size.
For the 10s row, you'll need to decode it in such a way that the 10 lever powers the 2 and 8 binary lines, the 20 lever powers the 16 and 4 binary lines, the 30 lever powers the 16, 8, 4, and 2 binary lines, etc. Then you add that to the binary output of the 1s row.
Although somewhat large, the easiest way to convert from the 10s levers to binary is with manhattan wiring. Run all your input lines in one direction, run all your output binary lines underneath perpendicular to the input lines, and place torches at the appropriate intersections.
… I had an idea for a non-analog way to do it. Would it be possible to have a zero place, and then put torches under the levers' wires all the way out to 99? It'd be tedious, big, and probably slow, but at least you'd have the fancy decimal input. After that you would just use a normal decimal-binary converter.
You mean 99 torches? Signal strength only goes up to 15, so I'm not sure what you mean here.
EDIT: Anyway, the traditional way to build a calculator is to only have a single bank of button inputs from 0 to 9. Pressing a button multiplies the register value by 10 and adds the single digit. Basically each digit input is an operation, just like the multiply key, the sign key, etc.
I think my first approach would be to run a line of redstone dust behind each row of levers, then use the signal strength at one end as the row's value.
What you do with that signal strength depends on what you need this for. If you just want to run a 7-segment display, you could feed those values directly into analog-to-BCD decoders for each digit. If you want to combine the two rows into a single binary value, then you can use analog-to-binary decoders and use an adder to combine them.
In a 1-wide space, there is no way to activate the middle piston without also activating either the top or bottom piston. This is because of something called quasi-connectivity: pistons have the same activation shape as doors -- just as activating the top of a door will also activate the bottom of the door, anything that activates the space above a piston will also activate the piston. There are some complications due to update distances, but basically that's the problem.
Two pistons on top of each other can be activated separately -- the bottom one directly and the top one by quasi-connectivity. If you can put at least one space in between two of your three pistons then you can activate them separately. Or you can just let two of them activate simultaneously.
0
Zero command blocks, survival build, 20 Hz (just like a setblock/fill clock):
0
The instant inverters on the wiki still work for me in 1.8.4.
I'm not aware of any instant circuits that use command blocks since commands that change blocks take 1 game tick to execute.
1
I think by "timer" you mean a circuit which will complete one cycle and then stop and wait for a new activation (some people use "timer" to mean a clock circuit which repeats its cycle indefinitely).
Here's a compact silent two-hopper clock circuit (adapted from a design by TitiSurMinecraft) which can be turned into such a timer by removing one of the torches on the right:
The torches on the left each stay on for half a cycle, and the torches on the right blink every half cycle. I think you might be able to adapt that to your purpose.
0
(1.8:) Place seven named armor stands in a row. Use an execute @r[type=ArmorStand,name=X] setblock command (with some other arguments) to randomly choose one of the armor stands and place a block of redstone next to it, powering an output. Then use a fill command to set all the possible blocks of redstone back to stone (or something, but not air since that would cause a block light recalculation) to reset the outputs.
Dragnoz has a good video discussing randomizers, including a method similar to this (though he uses falling sand entities instead of setblock which seems unnecessarily complicated):
0
I wrote the tutorial. If you explain how it is not sufficient, I may be able to improve it. What were you looking for that is not included?
And just to check, did you read the command description before you looked at the tutorial?
0
There's no way to tell if there's exactly 80 items in a hopper, you'd have to count the items as they go in. But you can tell when a hopper reaches 92 items (signal strength 5 from a comparator) then enable it for exactly 32 seconds to allow only 80 items to transfer into the furnace (except that the furnace can only hold 64 items to be smelted at a time, so easiest to use a second hopper between the two to hold the extra 16 items while the first few are being smelted).
3
inputs at lime wool, output at pink wool. Don't overlook the unpowered torch just before the pink wool.
0
Here's a smaller/faster item frame decoder by awedyssy (post #6):
If you replace the top torch with a full container then you can move the input to the same height as everything else.
I have some more analog-to-one-active decoders on one of my wiki pages that might give you ideas.
0
I don't do much on servers, so I'm only guessing here, but:
Tripwire hooks have an interesting property that they provide random block updates to their neighbors (and the neighbors of the block they're attached to) about once a minute (when they're updated by the three-updates-per-game-tick-per-chunk-section thing). The tripwire hook doesn't need to be part of a tripwire circuit for this to work, so it can be otherwise redstone-neutral.
If a tripwire hook is next to another redstone component, that block update might force the redstone component to check and update its own status, correcting any glitch.
If you want updates faster than about 1 minute, you can put over a dozen tripwire hooks around a BUD circuit, dropping the average update time to as little as 5 seconds, and have the BUD circuit update your clock (one changing component next to the redstone component which freezes)
Give it a try and let us know if it helped?
0
Frontrider's first post seems to imply that they don't realize the output 1s digit depends on more than just the four lowest bits of the input. I think they realize that later, and that this approach is only useful for converting from 4-bit binary to analog-coded decimal (ACD?), which is trivial, and not useful for larger binary encodings.
But implementing the double dabble algorithm with comparators might be feasible (first converting from binary to analog-coded hexadecimal). Comparators are good at subtraction (and thus, with a little more effort, at addition). The double dabble algorithm implemented on hexadecimal registers would require left bit shifts (equivalent to multiplying by 2, which is equivalent to adding a value to itself, so comparators could do it) and adding 3 (again, addition). There are additional checks that have to be made between registers and between steps that might cause this to stretch out, but I might play around with it. From experience, I'll guess it will end up being smaller by volume than RedRoboHood's but longer in length and much slower.
Converting from analog-coded decimal to one-active is pretty easy, and many 7SDs run off of one-active. For example, here's a 3-wide ACD-to-one-hot decoder that could be put under, say, Koala_Steamed's 7SD: .
The green clay is just an input tester, the circuit starts at the lime wool. The hopper produces a signal strength of 11.
1
The easiest way to go from BCD to 7SD is to first convert to one-active, then convert that to 7SD. Look up "minecraft 7-segment display" on youtube -- most of them go from one-active to 7SD.
0
The green blocks are just an analog clock to test the circuit, and the pistons are the output -- ignore them. The article is still in my userspace because it's still under construction and I haven't made a better picture yet.
The input is the first gold block on the right where the green blocks connect.
EDIT: I've added some schematics that should help you construct it.
0
So the 1s row can be converted easily using an A2B decoder. I have a couple examples on one of my wiki pages, depending on whether you're designing for speed or size.
For the 10s row, you'll need to decode it in such a way that the 10 lever powers the 2 and 8 binary lines, the 20 lever powers the 16 and 4 binary lines, the 30 lever powers the 16, 8, 4, and 2 binary lines, etc. Then you add that to the binary output of the 1s row.
Although somewhat large, the easiest way to convert from the 10s levers to binary is with manhattan wiring. Run all your input lines in one direction, run all your output binary lines underneath perpendicular to the input lines, and place torches at the appropriate intersections.
You mean 99 torches? Signal strength only goes up to 15, so I'm not sure what you mean here.
EDIT: Anyway, the traditional way to build a calculator is to only have a single bank of button inputs from 0 to 9. Pressing a button multiplies the register value by 10 and adds the single digit. Basically each digit input is an operation, just like the multiply key, the sign key, etc.
0
What you do with that signal strength depends on what you need this for. If you just want to run a 7-segment display, you could feed those values directly into analog-to-BCD decoders for each digit. If you want to combine the two rows into a single binary value, then you can use analog-to-binary decoders and use an adder to combine them.
0
Two pistons on top of each other can be activated separately -- the bottom one directly and the top one by quasi-connectivity. If you can put at least one space in between two of your three pistons then you can activate them separately. Or you can just let two of them activate simultaneously.