[*:smeav8t9]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.)
This is not as well understood as some would have you believe. If you go back to page 4 or 5, you can find a post of me tearing my hair out over this behavior, which is a lot more general than just that diagonal torch setup, and seems to act in unpredictable ways. The only thing I can think of at this point is reverse-engineering the code, but that's a major enterprise.
I forgot on my list the selection toolkit (select, cut, copy, paste, fill, clear, import from .schematic, rotate, mirror), which I promise is coming eventually, if I get the chance.
Quote from Edsonmilan »
I just suggest one:
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.
Note that the feature I just proposed above is a color palette modification, not a texture map. So you can make dirt brown, but not checkered. Parts of the code, including GIF export, rely on the prevalence of flat regions of color, so textures are farther down the list.
PS @ ahruman: You are using a Mac, yes? As you noted, I added some Mac-compatibility code to v2.2. Can you tell me if you get the modification dot in the close button when you modify something or animate? On Win, I am putting an asterisk in the window title, but Macs should not have the asterisk there. I don't have a Mac new enough to test Java 1.5, so I don't know if it is working.
PS @ ahruman: You are using a Mac, yes? As you noted, I added some Mac-compatibility code to v2.2. Can you tell me if you get the modification dot in the close button when you modify something or animate? On Win, I am putting an asterisk in the window title, but Macs should not have the asterisk there. I don't have a Mac new enough to test Java 1.5, so I don't know if it is working.
Yes, it’s working correctly. Now if only the menu bar was in the right place… ;-)
How so? Should I have instead detailed how to actually implement it? That's perhaps a little outside the scope of the thread. I'm having trouble understanding your retort.
[*:30un2fy0] The nature of the problem makes it hard to avoid getting stuck on local optima. If you just want a circuit that works, an explicit approach would be simpler and faster.
[*:30un2fy0] No obvious fitness function presents itself. How do you quantify how close an incorrect solution is to being correct? Small changes can lead to very different output truth tables.
Couldn't you measure fitness according to the desired output truth table? Indeed GA's have been used to design circuits before with success. Usually it results in very strange connections though, with seemingly superfluous connections/transistors/etc, but in practice when those are removed, it fails to function. I honestly believe it couldwould work, but then one has to actually build said circuits in the game. Given the nature of GA's I agree it might not be the correct approach given the context of the game world we're given as it is likely to produce messy, spaghetti layouts, but it's not overall a stupid idea as you seemed to imply in what I took as a rather rude reply to my first post, working on the theory that a GA would make the job of actually designing it faster than the explicit model, as according to the math problems posted above.
Couldn't you measure fitness according to the desired output truth table?
No. A single torch in the right place can invert the entire truth table, or a subset of it – potentially any subset. For example, these two circuits are both 50 % fit as NAND gates by the trivial test, yet one of them needs only one change to work:
If you penalized size, which of course you would, the right one would easily optimize to a smaller but still wrong circuit.
Quote from UnitSeven »
but it's not overall a stupid idea as you seemed to imply in what I took as a rather rude reply to my first post,
By the way, Baezon, when you implement that rotating stuff it would be nice to have an option to open files with north at the top instead of the left. I know it’s an odd thing to want, but I’m sure I’m not entirely alone. :-)
At the risk of sounding like a n00blet, I can't get this running. I'm getting this message popup
"Could not find the main class: C:\Users\Omega_2\Desktop\MCRedstoneSim.jar. Program will exit."
Stubborn java, just hoping it's java screwing up and mot the app. This looking great, btw.
Rollback Post to RevisionRollBack
YOUR MINECRAFT ACCOUNT IS YOUR RESPONSIBILITY, TREAT IT AS IF IT WERE A WAD OF CASH.
Whenever i scroll my mouse wheel it skips one item. Got a Logitech G5 v2.
Tried altering the number of lines that it would scroll with no effect.
It just scrolls through wire, wire, wire, button, door.
When i expect it to scroll wire, torch, wire, torch...
Possible solution?
I've been having the same problem for quite some time now, although it wasn't always like that. I can remember that it was working normally sometime in the past.
Same problem here. Also a Logitech mouse, don't know which type.
Whenever i scroll my mouse wheel it skips one item. Got a Logitech G5 v2.
Tried altering the number of lines that it would scroll with no effect.
It just scrolls through wire, wire, wire, button, door.
When i expect it to scroll wire, torch, wire, torch...
Possible solution?
I've been having the same problem for quite some time now, although it wasn't always like that. I can remember that it was working normally sometime in the past.
Same problem here. Also a Logitech mouse, don't know which type.
The simulator flickers when a circuit gets in a self-contradictory state (a.k.a. a one-clock). The game fixes this with random burnout, but in the sim you need to fix it manually.
For circuits which have stable states, this can generally be done by forcing it into such a state by placing a torch at an appropriate place – in this case, at the output pin – and then deleting it. After that, it’ll work fine unless you cycle it too fast.
Me too. But then, redstone is really a cellular automaton (at least in the idealized form used in the simulator), not a simulation of electricity. Real EEs don’t get an implicit, synchronized clock.
Quote from ReaperAlex »
now, dare i ask, how would you work out where to place the torch to stabilize it? with any luck i might learn something :smile.gif:
Familiarity with the particular circuit. :-) But here are some more general tips:
[*:387g41ej] Every redstone latch has an RS NOR latch in it somewhere, i.e. two NOTs feeding into each other. A stable state requires them to have opposite values. If the RS NOR sub-latch is blinking, force one side high for a couple of ticks.
[*:387g41ej] If you’re designing a circuit, you should know what the valid states are. Pick one, and force the relevant bits of circuit high. Wait for the dependent parts to go low, then remove the extra torches. If it starts flickering again, you have unexpected feedback somewhere.
[*:387g41ej] The most common forms of unexpected feedback, in my experience, are wires passing over torches and diagonal transfer. The latter occurs when a block is powered from below by a torch, and powers wires adjacent to it. (These are essentially the same thing; in the first case, the wire being powered is above the block rather than to a side.)
[*:387g41ej] It’s possible to generate a one-tick pulse, but you really don’t want to. No, really.
This is not as well understood as some would have you believe. If you go back to page 4 or 5, you can find a post of me tearing my hair out over this behavior, which is a lot more general than just that diagonal torch setup, and seems to act in unpredictable ways. The only thing I can think of at this point is reverse-engineering the code, but that's a major enterprise.
I forgot on my list the selection toolkit (select, cut, copy, paste, fill, clear, import from .schematic, rotate, mirror), which I promise is coming eventually, if I get the chance.
Note that the feature I just proposed above is a color palette modification, not a texture map. So you can make dirt brown, but not checkered. Parts of the code, including GIF export, rely on the prevalence of flat regions of color, so textures are farther down the list.
PS @ ahruman: You are using a Mac, yes? As you noted, I added some Mac-compatibility code to v2.2. Can you tell me if you get the modification dot in the close button when you modify something or animate? On Win, I am putting an asterisk in the window title, but Macs should not have the asterisk there. I don't have a Mac new enough to test Java 1.5, so I don't know if it is working.
Yes, it’s working correctly. Now if only the menu bar was in the right place… ;-)
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
How so? Should I have instead detailed how to actually implement it? That's perhaps a little outside the scope of the thread. I'm having trouble understanding your retort.
[*:30un2fy0] The nature of the problem makes it hard to avoid getting stuck on local optima. If you just want a circuit that works, an explicit approach would be simpler and faster.
[*:30un2fy0] No obvious fitness function presents itself. How do you quantify how close an incorrect solution is to being correct? Small changes can lead to very different output truth tables.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
couldwould work, but then one has to actually build said circuits in the game. Given the nature of GA's I agree it might not be the correct approach given the context of the game world we're given as it is likely to produce messy, spaghetti layouts, but it's not overall a stupid idea as you seemed to imply in what I took as a rather rude reply to my first post, working on the theory that a GA would make the job of actually designing it faster than the explicit model, as according to the math problems posted above.No. A single torch in the right place can invert the entire truth table, or a subset of it – potentially any subset. For example, these two circuits are both 50 % fit as NAND gates by the trivial test, yet one of them needs only one change to work:
If you penalized size, which of course you would, the right one would easily optimize to a smaller but still wrong circuit.
I didn’t respond to your first post.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
The round grey elements are levers.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
"Could not find the main class: C:\Users\Omega_2\Desktop\MCRedstoneSim.jar. Program will exit."
Stubborn java, just hoping it's java screwing up and mot the app. This looking great, btw.
Life screws us all.
Try holding down the Control key.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
Open the .jar file
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSame problem here. Also a Logitech mouse, don't know which type.
Me too. Not a Logitech mouse. :-)
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
Jerk. You traveled forward in time and took my idea D:
No seriously though, this is awesome!
Mac always closes the Windows >:sad.gif:
For circuits which have stable states, this can generally be done by forcing it into such a state by placing a torch at an appropriate place – in this case, at the output pin – and then deleting it. After that, it’ll work fine unless you cycle it too fast.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE
…dammit, Jim!
Me too. But then, redstone is really a cellular automaton (at least in the idealized form used in the simulator), not a simulation of electricity. Real EEs don’t get an implicit, synchronized clock.
Familiarity with the particular circuit. :-) But here are some more general tips:
[*:387g41ej] Every redstone latch has an RS NOR latch in it somewhere, i.e. two NOTs feeding into each other. A stable state requires them to have opposite values. If the RS NOR sub-latch is blinking, force one side high for a couple of ticks.
[*:387g41ej] If you’re designing a circuit, you should know what the valid states are. Pick one, and force the relevant bits of circuit high. Wait for the dependent parts to go low, then remove the extra torches. If it starts flickering again, you have unexpected feedback somewhere.
[*:387g41ej] The most common forms of unexpected feedback, in my experience, are wires passing over torches and diagonal transfer. The latter occurs when a block is powered from below by a torch, and powers wires adjacent to it. (These are essentially the same thing; in the first case, the wire being powered is above the block rather than to a side.)
[*:387g41ej] It’s possible to generate a one-tick pulse, but you really don’t want to. No, really.
Imitating greatness: 16-bit Hack ALU design
KEEP CALM AND EAT CAKE