That’s not a useful question. Many of us have run it, and in fact I’m running it right now. Clearly, then, there is a way to run it. Would you like to try again with a more specific question?
In case it's useful for anyone working on circuits, I got an Earle Latch working. For anyone who doesn't know, this is basically a standard level-triggered D-latch, but it doesn't have the uneven tick delays when changing Q.
Specifically, D-latches take two ticks to bring Q high, but three ticks to bring it low, which can easily cause problems in partially or fully asynchronous circuits.
The Earle Latch, however, has a flat two-tick delay for any change in the output, making it extremely useful for time-sensitive or high-speed redstone circuits. However, this design is hard to miniaturize as it makes use of the 15-block signal limit - if that limit ever rises, this gate will fail to work (and if you miniaturize it, you run the risk of shortening the clock line to under that limit with the same result). Also, in this specific design I upped the signal delay to 4 by placing a pair of repeaters - you can remove them if you want, but be mindful that you need to have the outputs of the gates driving this gate close enough to overcome the lengthened clock line!
Here’s a 1×1×0 reduction, achieved by (a) putting the clock bus in a tunnel, folded under the gates and (:cool.gif: removing the unneeded raised straight on the fourth row. (The button is C and the lever is D. The clock bus is actually two steps longer than it needs to be, so the long bit can be moved over one step to the left. C could also connect to the bottom opening of the tunnel, although you’d need a repeater immediately by the exit.)
Here’s a version that’s more compact in 2D, but taller since it uses a bridge as well as a tunnel. (Note that the └ wire behind the button is functionally a ┴. “Natural wiring” mode gets this right but gets the wires for output torches wrong.) Schematic
And here’s a possible optimization for the bottom side, but I’m not sure how to integrate it into my tunnelled designs. (In this, the second image is one layer down; in the others, it’s two down.)
As it turns out, the pulse doesn’t happen in-game. Win!
Edit:…And on further investigation it doesn’t happen if you take out the two blocks on the top layer (not visible in the pictures, but in the schematic file) that are causing that diagonal transfer I complained about before. Doh!
I also found that, with some crouching and careful aim, the tunnel can be dug and wired without extra excavation.
Hey all. First I'd like to compliment the OP on this amazing simulator! :smile.gif: It has saved me a lot of time and has increased the complexity of circuits I can experiment with.
I just registered to post an idea / bug fix that I thought the creator might be interested in. I'm in the middle of creating/bugtesting a circuit where redstone torch delay is critical to keep track of, and I noticed a small inaccuracy in the editor. If it's already been noticed then forgive me, I didn't have much time to read the entire thread so I just skimmed over it.
Basically if you have two redstone torches situated like this:
Where the torches are on the sides of the blocks and the blocks are oriented in a North/South direction, the torch delay for a circuit passing through will only be one torch's worth, not two. This way one can make a circuit delayed by one tick without inverting the signal. Here's a top-down view of the circuit to help make it more clear:
(Where up is North and down is South, or vice versa)
The top is the repeater described above, while the bottom is a simple inverter. In minecraft a signal at the left arrives at the right at exactly the same time through both lines (as long as the repeater is oriented North/South). In Redstone sim, the repeater is treated as two torches and there is a delay between the Q signal and its inverse. You can test this in game by AND gating the two wires together, and noticing that there is a period where the redstone in the gate flashes if there's any delay at all, and absolutely no flashing if they're equivalent like the setup above. (even though the redstone flashing isn't long enough to turn on the torch, it will add up in certain circuits).
Like I said it's a minor issue, as I just have to count the delay in sim just using the normal torch setups and add repeaters in game to make up the difference. But it would be nice if I could do it all before booting up minecraft. :smile.gif:
Some sort of commenting/labeling feature would be very helpful. Sometimes I return to a schematic after a day or two and think "What the hell was I trying to do here?"
I think the region labelling approach I used in this image worked very well:
The outlines are drawn with 100 % opacity, the fill at 25 %. It’s possible that some colour combinations could be confusing, so the ability to hide and show the labelled regions would also be useful.
Sorry so much for being gone for so long, but studies have been hell and I haven't had much time for breathing or other recreational activities. I've released v2.2, which consists of the work I had been doing before I left, so I can't remember what I did. I do know, though, that I fixed the "Save As..." bug and added the shadow block, which appears transparent on GIF exports. Maybe it has other goodies!
I have received several feature requests and will list them later (so I don't forget), but I am short on time right now.
I have received several feature requests and will list them later (so I don't forget), but I am short on time right now.
Not a problem. Heck, I haven’t been near my own code projects in ages. (Full disclosure: partly because I’ve been distracted by writing my own redstone app…)
Found one forgotten fix already: menu items are now bound to command-foo instead of control-foo on Macs.
Would it be possible to have a "Bluestone" option for people like me who are colorblind? Basically have everything that is currently drawn in red drawn in blue instead. I don't have too much trouble in game because the redstone is all bubbly when it's on, but I'm having trouble distinguishing off vs on in the simulator.
This would work by the user specifying parameters for the maximum size of the final design, and then the sim would by bruteforce create every design (also complete nonsense) possible within those parameters. For each created design, it would try all possible states of all switches(the input for the design) and compare them with all states of doors(the output for the design) and see if the behaviour is similar to the original design.
Um. Let’s crunch some numbers, shall we? (I haven’t double-checked this, but the result should be within a few orders of magnitude of right.)
For simplicity, let’s assume we’re working only on stateless circuits (i.e., ones that are only determined by their inputs). In this view, the initial on/off state of each internal component doesn’t matter when generating the possible layouts, so there are eighteen possible cell states to consider.
Now let’s say you’re working on a quite simple component, and specify a maximum size of 6 × 6 × 12 cells. That’s 432 cells.
That gives us 18⁴³² possible combinations = 10^(log₁₀ 18 × 432) ≈ 10⁵⁴².
If you simply iterate through the possible combinations, most changes will modify only one cell, and can be quick-rejected if they don’t generate a circuitry component that interacts with a neighbour. Let’s be really generous and say the app can generate and test a candidate in an average of 1000 cycles. Let’s also say you’re running on an 8-core, 3 GHz system with no other load. That’s 2.4 × 10⁷ candidates per second.
Testing all candidates would then take 4.2 × 10⁴⁴³ seconds.
The universe is roughly 4.3 × 10¹⁷ seconds old.
All things considered, I think you’d be better off working out a NOR gate network from a given truth table and working out how to fold it into the smallest possible space. Not that this is easy, but it’s certainly doable.
To be fair, I overestimated the size of a “quite simple component” there. To develop howlingmonkey’s 5×6×3 adder design at the same speed would only take about 5×10¹⁵ seconds, so we’re well within the lifetime of the universe so far. :-)
I just have a question
What are the other two things on the palette that doesn't appear in the readme here's an image explaining them (two red circles):
Edit: Oh also the second circle (the torch with wires) I right click it to put it on the screen but it makes the torch over block one so Idk what happens.
To be fair, I overestimated the size of a “quite simple component” there. To develop howlingmonkey’s 5×6×3 adder design at the same speed would only take about 5×10¹⁵ seconds, so we’re well within the lifetime of the universe so far. :-)
I have actually considered writing an automatic redstone circuit builder, and as you have pointed out, a brute-force search is completely out of the question. I separate the problem into two: how to generate the appropriate network of torches that produce the desired output, and how to lay out the torches and wires, given the network, to fit in the smallest space.
The first part is actually quite doable, and I have used the approach to improve some logic gate designs. The most extreme example of a computer-generated network is the 3-tick 7-segment display I posted on the logic gate thread a while back. That one took most of a day, though, and needed frequent intervention in order to relax the constraint of "perfect" to "near-perfect" for time's sake. And it only has 4 inputs! The possibilities increase super-exponentially: the number of n-input gates is 2^2^n, and you may need to search the whole space thousands of times in order to work your way all the way through from output backwards to the inputs.
The second part is much more open-ended, and I have yet to find a suitable algorithm for tracing wires. Just figuring out if two wires are connected is no trivial task. Ideas?
Quote from UnitSeven »
What you need is a genetic algorithm.
That's not an idea, that's a buzzword.
Quote from Edsonmilan »
I just have a question
What are the other two things on the palette that doesn't appear in the readme here's an image explaining them (two red circles):
Edit: Oh also the second circle (the torch with wires) I right click it to put it on the screen but it makes the torch over block one so Idk what happens.
The left circled one is a block-on-block tile, and the right one is a torch-on-wire tile. The torch-on-wire tile requires a wall adjacent to the torch, or else it will not be able to attach and will default to building a block below (overwriting the wire).
List of features on my to do list:
[*:3tnva2wl]Alternative to middle-click (Shift-left-click)
[*:3tnva2wl]"Bluestone" (i.e. customizable color palette)
[*:3tnva2wl]Glass -> Air (not dirt)
[*:3tnva2wl]Undo
[*:3tnva2wl]Labeling
[*:3tnva2wl]Possibly something I've forgotten...
[*:3tnva2wl]Fix Minecraft so that redstone behaves rationally
[*:17sr5zuz]Copy and paste, including between documents. Failing that, a way to merge one document into another. (If I continue my computer, there’s no way I’m going to build the other components in the same document, it’s just too messy.) This could possibly be used to build a component library: Insert XOR gate here…
[*:17sr5zuz]Flip horizontal, flip vertical, rotate clockwise and rotate anticlockwise commands. Preferably working on a selection, but full-circuit would be useful, especially combined with the previous point.
[*:17sr5zuz]Simulation of the north/south-facing diagonal torch 1-tick update glitchamabob. (Combining this with rotate commands could lead to hilarity for the user, but that’s Notch’s fault.)
No hurry on my account, I wrote a command-line tool to do these things last night. (I’ll post it somewhere soon, but it’s Mac-only.) But they’re things that should, at least, be on the “nice-to-have” list. :-)
That’s not a useful question. Many of us have run it, and in fact I’m running it right now. Clearly, then, there is a way to run it. Would you like to try again with a more specific question?
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
Specifically, D-latches take two ticks to bring Q high, but three ticks to bring it low, which can easily cause problems in partially or fully asynchronous circuits.
The Earle Latch, however, has a flat two-tick delay for any change in the output, making it extremely useful for time-sensitive or high-speed redstone circuits. However, this design is hard to miniaturize as it makes use of the 15-block signal limit - if that limit ever rises, this gate will fail to work (and if you miniaturize it, you run the risk of shortening the clock line to under that limit with the same result). Also, in this specific design I upped the signal delay to 4 by placing a pair of repeaters - you can remove them if you want, but be mindful that you need to have the outputs of the gates driving this gate close enough to overcome the lengthened clock line!
Note that in this image, C, D, and Q are all low.
Schematic, modified version
Here’s a version that’s more compact in 2D, but taller since it uses a bridge as well as a tunnel. (Note that the └ wire behind the button is functionally a ┴. “Natural wiring” mode gets this right but gets the wires for output torches wrong.)
Schematic
And here’s a possible optimization for the bottom side, but I’m not sure how to integrate it into my tunnelled designs. (In this, the second image is one layer down; in the others, it’s two down.)
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
Bah. I almost have a 6-wide version (with an additional tunnel layer), but I forgot that this counts as a power transfer:That keeps tripping me up.Whoops! Turns out that wasn’t the real problem. 7×6×6 version:
Schematic
This one is less well-behaved, though – it pulses the output on the second tick when going from C=0 D=0 to C=1 D=0.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
Edit:…And on further investigation it doesn’t happen if you take out the two blocks on the top layer (not visible in the pictures, but in the schematic file) that are causing that diagonal transfer I complained about before. Doh!
I also found that, with some crouching and careful aim, the tunnel can be dug and wired without extra excavation.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
I just registered to post an idea / bug fix that I thought the creator might be interested in. I'm in the middle of creating/bugtesting a circuit where redstone torch delay is critical to keep track of, and I noticed a small inaccuracy in the editor. If it's already been noticed then forgive me, I didn't have much time to read the entire thread so I just skimmed over it.
Basically if you have two redstone torches situated like this:
Where the torches are on the sides of the blocks and the blocks are oriented in a North/South direction, the torch delay for a circuit passing through will only be one torch's worth, not two. This way one can make a circuit delayed by one tick without inverting the signal. Here's a top-down view of the circuit to help make it more clear:
(Where up is North and down is South, or vice versa)
The top is the repeater described above, while the bottom is a simple inverter. In minecraft a signal at the left arrives at the right at exactly the same time through both lines (as long as the repeater is oriented North/South). In Redstone sim, the repeater is treated as two torches and there is a delay between the Q signal and its inverse. You can test this in game by AND gating the two wires together, and noticing that there is a period where the redstone in the gate flashes if there's any delay at all, and absolutely no flashing if they're equivalent like the setup above. (even though the redstone flashing isn't long enough to turn on the torch, it will add up in certain circuits).
Here is the thread where I found this repeater, and let me tell you it was a Godsend for the circuit I'm designing:
http://www.minecraftforum.net/viewtopic.php?f=35&t=64559&start=0
Like I said it's a minor issue, as I just have to count the delay in sim just using the normal torch setups and add repeaters in game to make up the difference. But it would be nice if I could do it all before booting up minecraft. :smile.gif:
(edit: Sheesh, didn't mean to post that much...)
assert("Everything will be okay.");The outlines are drawn with 100 % opacity, the fill at 25 %. It’s possible that some colour combinations could be confusing, so the ability to hide and show the labelled regions would also be useful.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
I have received several feature requests and will list them later (so I don't forget), but I am short on time right now.
Not a problem. Heck, I haven’t been near my own code projects in ages. (Full disclosure: partly because I’ve been distracted by writing my own redstone app…)
Found one forgotten fix already: menu items are now bound to command-foo instead of control-foo on Macs.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAs you can see, for whatever reason, none of the torches go off where they should. Am I just using the wrong pieces?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat you need is a genetic algorithm.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
What are the other two things on the palette that doesn't appear in the readme here's an image explaining them (two red circles):
Edit: Oh also the second circle (the torch with wires) I right click it to put it on the screen but it makes the torch over block one so Idk what happens.
I have actually considered writing an automatic redstone circuit builder, and as you have pointed out, a brute-force search is completely out of the question. I separate the problem into two: how to generate the appropriate network of torches that produce the desired output, and how to lay out the torches and wires, given the network, to fit in the smallest space.
The first part is actually quite doable, and I have used the approach to improve some logic gate designs. The most extreme example of a computer-generated network is the 3-tick 7-segment display I posted on the logic gate thread a while back. That one took most of a day, though, and needed frequent intervention in order to relax the constraint of "perfect" to "near-perfect" for time's sake. And it only has 4 inputs! The possibilities increase super-exponentially: the number of n-input gates is 2^2^n, and you may need to search the whole space thousands of times in order to work your way all the way through from output backwards to the inputs.
The second part is much more open-ended, and I have yet to find a suitable algorithm for tracing wires. Just figuring out if two wires are connected is no trivial task. Ideas?
That's not an idea, that's a buzzword.
The left circled one is a block-on-block tile, and the right one is a torch-on-wire tile. The torch-on-wire tile requires a wall adjacent to the torch, or else it will not be able to attach and will default to building a block below (overwriting the wire).
List of features on my to do list:
[*:3tnva2wl]Alternative to middle-click (Shift-left-click)
[*:3tnva2wl]"Bluestone" (i.e. customizable color palette)
[*:3tnva2wl]Glass -> Air (not dirt)
[*:3tnva2wl]Undo
[*:3tnva2wl]Labeling
[*:3tnva2wl]Possibly something I've forgotten...
[*:3tnva2wl]Fix Minecraft so that redstone behaves rationally
Might I suggest:
[*:17sr5zuz]Copy and paste, including between documents. Failing that, a way to merge one document into another. (If I continue my computer, there’s no way I’m going to build the other components in the same document, it’s just too messy.) This could possibly be used to build a component library: Insert XOR gate here…
No hurry on my account, I wrote a command-line tool to do these things last night. (I’ll post it somewhere soon, but it’s Mac-only.) But they’re things that should, at least, be on the “nice-to-have” list. :-)[*:17sr5zuz]Flip horizontal, flip vertical, rotate clockwise and rotate anticlockwise commands. Preferably working on a selection, but full-circuit would be useful, especially combined with the previous point.
[*:17sr5zuz]Simulation of the north/south-facing diagonal torch 1-tick update glitchamabob. (Combining this with rotate commands could lead to hilarity for the user, but that’s Notch’s fault.)
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
add some texture to the blocks so we don't get confused I know you can change it but I just get confused sometimes of which block I am using.