User talk:Sorceror Nobody

Nice clocks!
That hopper clock and the multiplier look very promising -- long-period clocks have classically been a PITA, and these are comparatively small for clocks that can go up into multi-minute cycles. Once you're sure of them, feel free to add them (via LoadBox) to the Clock circuit page. --Mental Mouse 12:46, 4 June 2013 (UTC)
 * I've put together a draft for the hopper clock entry in my second sandbox, if you want to go over it and check I've not messed up on style guide or anything. I've displayed it as a h4 under the existing hopper section, but maybe that's just me :P
 * As for the multiplier, I could add that as well, but I have an alternate suggestion. A state cycler -- that is to say, a circuit that always has exactly one of its outputs high, and when triggered, moves to the next output in the loop -- is something I spent much time trying to find on this wiki. Obviously we have plenty of memory circuits, but nothing I could readily identify as a direct state cycler. So I'm wondering if it might not be an idea to make that the main thing we add, and then for the clock page, point out something of the form, "and you can multiply clock periods using a slightly modified state cycler" -- Sorceror Nobody 14:08, 4 June 2013 (UTC)
 * It mostly looks good, I have a few suggestions for tweaks:
 * I don't know what the  bit is about, can you explain that to me?
 * For the headers, I would suggest changing the h3 header to just "Hopper Clocks" (that is, now a proper category), and adding an h4 "Basic Hopper Clocks" for the existing one, all before the h4 for your clock. Also the circuit variations should be set off with "Variations:" (that is, not a header, just a paragraph label), there's a couple of examples of that in the existing pages.
 * I'd have no problem with seeing both the state cycler in Miscellaneous circuits, and also the clock multiplier in with Clock circuit, with a note to the effect that one is a simplified (and more compact) version of the other. They're both important contributions!
 * Under variations for the hopper clock and the multiplier, you might briefly note that the pulses can easily be reduced to a short pulse with an edge detector or monostable circuit, or extended to 50/50 (with a period doubling) with a toggle.

Thanks for your work on this! --Mental Mouse 20:18, 4 June 2013 (UTC)
 * And looking back, I see two moderately big things I missed above: The smaller is that the hopper clock is flat, but not 1-high, it's 2 high counting support blocks.  The bigger thing is that the text should go into the main article, with just the schematics in a LoadBox. --Mental Mouse 20:36, 4 June 2013 (UTC)
 * The  is just because my sandbox is transcluding itself; it wouldn't be used in the actual thing. Onlyinclude means whatever is inside the tags is the only part included, so the transclusion doesn't attempt to transclude the transclusion itself ad infinitum (it's basically the inverse version of the   tag, if you're familiar with that). Includeonly means it only shows up when transcluded, otherwise there would have been two copies of the section on the page.
 * Makes sense.
 * I'll probably work on that tomorrow or Thursday, then.
 * Well, the hopper clock design, as noted, already has an edge detector built in, but I can comment on a pulse lengthener, sure. As for the multiplier, an edge detector is actually entirely requisite for chaining multipliers, so it would definitely get mentioned. Not entirely sure what you mean by "50/50", but yeah, toggles are easy enough; I can add that.
 * Two high; use loadbox. Got it.
 * -- Sorceror Nobody 21:57, 4 June 2013 (UTC)
 * Thanks for explaining the directives, that's a cool trick. By "50/50" I just meant a clock cycle that's half-on, half off, which you'd get by toggling on your chosen edge.  Can you clarify needing an edge detector for chaining multipliers?  I haven't built one yet, but it looks to me like it's passing the pulse between latches on the pulse edges.  --Mental Mouse 22:32, 4 June 2013 (UTC)
 * Trust me, build two multipliers, then feed the unmodified output of one directly into the latch-powering line of the other. You'll see exactly what the problem is :P
 * Basically, the latches have to be on all the time apart from when the input circuit triggers. So the input has to be a short pulse (or rather, inverse pulse). But the multiplier output is not a short pulse, because each latch in the loop is high for a duration exactly equal to the input clock's period.
 * EDIT: On reflection, I'm being an inconsistent derp in what components I'm referring to when I talk about the multiplier. Okay, so, the multiplier itself is technically only the two rows of repeaters and the surrounding redstone, i.e. the adapted state cycler. The schematic in my sandbox, however, shows an inbuilt edge detector/short (inverse) pulse generator attached to the latch power line. And yes, the design including that part is totally chainable with no additional modification. So I guess that's my bad for forgetting the schematic >.>


 * EDIT AGAIN: In fact, the chain can be made fairly compact, since you can place the solid block that holds the torch right on the output of the last latch, and pull the repeater next to it from the adjacent wire. So you actually save three pieces of redstone per chained multiplier that way: one that is replaced by the solid block, and two that would otherwise have been used in constructing the edge detector -- Sorceror Nobody 16:49, 5 June 2013 (UTC)
 * *reduces indent*
 * Also, isn't the 50/50 and period doubling with a toggle something that applies to all clocks, and therefore should be added as a section on the clock page dedicated to externally rather than internally modifying the output of a clock? Hell, that's precisely the kind of section the multiplier would belong in, too -- Sorceror Nobody 17:36, 5 June 2013 (UTC)
 * Memory circuit notes period doubling with TFFs, but if you're already using multipliers (especially chained), I suspect their main use would be regularizing the period. Period doubling with TFFs probably should be mentioned in the Clock circuit intro, if it isn't already.  I can't check or compare diagrams now (heading off to work) but I'll try to check later.  Indeed, there's at least four ways here to boost a clock's period: expand the repeater loop, expand the multiplier, chain the multiplier, or add a TFF.  And that's not counting factorial combination.... Mental Mouse 13:07, 6 June 2013 (UTC)
 * Yeah, it definitely sounds like clock period boosting (or our knowlege of it, anyway) is rapidly becoming a broad field to cover, and I really think it deserves a whole dedicated section, since fundamentally speaking it isn't part of the design of any one clock, it's a general set of methods for all clocks. In any case, my sandbox has been edited, so if you want to give it another look over when you get back, be my guest. You can tweak some of the wording as well if you want to, I don't mind -- Sorceror Nobody 13:33, 6 June 2013 (UTC)
 * Do you want to write a start for that section on extending clock periods, wrapping your clock multiplier? If you prefer, I can do that.  I'd also suggest including the extension you have above here.  I do have one more thought about the circuit, which you might want to change before publishing:  As shown, it moves the signal two blocks to the side (down in the diagram) for each multiplier bank, and the extension does another.  It looks to me like you can bring the bank circuit into line pretty easily, by taking the input below its block, and adding a spot of redstone to run the output up one block, and something similar for the extension.  If the edge detectors still poke out to the side(s) every 14 blocks or so, that's at least better than the line wandering sideways.  (Of course, you could also mirror-image alternate banks.)  --Mental Mouse 21:04, 6 June 2013 (UTC)

And... I just built the multipler, and promptly got smacked by a Blinding Flash Of The Obvious: What is supposed to be lighting that lower redstone loop? You have one repeater lit, but no apparent power source. (Looking up the video now...) --Mental Mouse 22:02, 6 June 2013 (UTC)
 * Looking at https://www.youtube.com/watch?v=yiDqoKn7Vnc and https://www.youtube.com/watch?v=JY06iEeowCw, it seems that multiplier is trickier than it looks -- it's actually a clock that you need to start separately, and the pulse you use has to relate to the input clock pulse in some way... It also occurs to me that the video dates from before the Redstone Update. So far, I've got one sort-of-working, in part by setting the latched repeaters to 3 ticks each, but it's not multiplying the input by the multiplier, so much as vice versa -- that is, the multiplier's looping pulse is the one that actually gets output.   I need to ask:  Have you built this and gotten it working? --Mental Mouse 22:50, 6 June 2013 (UTC)
 * Multiplier trial 2013-06-06.png Here is a screenshot of the best one I've gotten so far, by adding a different edge detector and an inverter to the input clock. --Mental Mouse 23:22, 6 June 2013 (UTC)


 * OK, I've now gotten the original design working, and understand the works much better, so I'm sorry for (and retract) the aspersions I cast above. This circuit definitely needs more discussion in the article of the multiplier's nature and limits.  So far, I've figured this much out:
 * In effect, it is a repeater-only clock loop that can be "frozen" by a single line. That line is driven through an edge detector, and the edge detector's pulse length needs to "match" the delays on the latched repeaters -- that is, the ED's repeater needs to be set 2 higher than the latched repeaters.  The original poster says at one point that the latched repeater's delays are "multiplied" by the input clock; this is wrong -- their delays don't actually matter, as long as they match the pulse length.  (Also, the input clock must be no shorter than their delay) The latches are just counting off rising edges of the input line, thus the connection to your state cycler invention.
 * --Mental Mouse 01:39, 7 June 2013 (UTC)
 * Also, here's a version with input and output inline, even with extension. SN's Extended Multiplier Inline.png  It's 5 wide counting the EDs, and the banks butt end-to-end. --Mental Mouse 02:28, 7 June 2013 (UTC)
 * I've done some edits to your sandbox, including LoadBoxing the inline version. Are you ready for it to go onto the page? --Mental Mouse 17:36, 7 June 2013 (UTC)
 * Looks pretty good; I've just tweaked it for grammar and to do away with the unpleasant quantity of brackets, as well as making T flip-flop into a link to the memory circuits page. If you have no further alterations to make, go ahead and add it wherever you think it best fits.
 * There's also my hopper clock, still in my Sandbox2, ready to be added if it's now adequately in line with the style guide. That was actually the sandbox I was inviting you to edit, but it's okay, I should have been clearer :P
 * EDIT: Also, how will we credit the hopper clock? I mean sure I invented it independently, but I'd be surprised if I'm the first to come up with that design. First confirmed appearance, maybe? Should I throw together a YT video over the weekend to stake my claim? :P I'm not really hugely bothered about being TEH FIRST!!!1! or anything, but obviously credit is nice if it's deemed appropriate -- Sorceror Nobody 21:22, 7 June 2013 (UTC)
 * For the hopper clock, "First known appearance:" :-)  (Actually, I should be using that always, but sometimes I forget.)  If someone comes up with a prior YT video, we can always change it....  It's certainly a non-trivial development.  --Mental Mouse 22:39, 7 June 2013 (UTC)

OK, I added both of them. For the hopper clock I stripped the "code" tags, because using it for individual numbers in text looked weird. It occurs to me belatedly, that perhaps the version without the edge detector should be the default, and "add an edge detector" the variation -- quarter-period pulses are natural to this design. On the other hand, the ED does allow for the switch to turn off the output immediately. (No hurry on that in any case.) --Mental Mouse 23:59, 7 June 2013 (UTC)
 * I would have done that, but yeah, the switch is useful. Also I figured the layout of the ED is slightly unusual, result of my efforts to minimise the footprint, and so it's perhaps sufficiently not obvious how it would be laid out that we would end up with two schematics, one with and one without, which seems rather unwieldy (I hate clutter :3). But really, it's pretty clear what the schematic is for without, because the core clock is utterly symmetrical. I won't object to adding the schematic for without, but I think the one for with definitely needs to stay -- Sorceror Nobody 11:48, 8 June 2013 (UTC)
 * Fair enough. BTW, it also occurred to me that the multiplier could be folded vertically like the vertical clock -- that would reduce it to 4 wide, and add a block or two at each end, but halve the "bulk" length. On the other hand, I'm still looking at how the tradeoffs work for multiple banks, and at first glance the breakpoint for a new bank is too short to make that worthwhile. --Mental Mouse 12:19, 8 June 2013 (UTC)
 * As expected, someone (Sethbling) came up with the same hopper design ages ago. On the other hand, he doesn't include the ED and lever, which are pretty handy additions, and not totally generic ones since the lever also stops the clock itself (eventually). He also doesn't discuss the option of altering the clock by taking out two of the comparator circuits. So I'm not the first to design the core clock, but as far as I can see I'm the first to make those additions. Credit it however you think is best, I guess. Perhaps First appearance (Sethbling), enhanced version (me) or something like that? Idk.
 * My video: http://www.youtube.com/watch?v=XCDEXtalF9Q
 * Sethbling's: http://www.youtube.com/watch?v=ThsaI0iOZGg
 * -- Sorceror Nobody 14:22, 8 June 2013 (UTC)
 * EDIT: Also while I was looking at Sethbling's, I stumbled across another useful hopper circuit that outputs a settable pulse length. So, a pulse circuit rather than a clock. Might be worth adding to the wiki
 * http://www.youtube.com/watch?v=dNZhugdQwdE
 * -- Sorceror Nobody 14:30, 8 June 2013 (UTC)
 * OK, I edited the credits. And that other circuit does look promising, (as does the comparator SR ;-) ) I'll work them up sometime (unless you beat me to it). --Mental Mouse 20:09, 8 June 2013 (UTC)
 * Also, in case you hadn't noticed, I'm musing on efficiency issues in Talk:Clock circuit. --Mental Mouse 23:19, 8 June 2013 (UTC)
 * Oh yeah, I did some early calculations myself, primarily working out when it's worthwhile to use a multiplier at all. But I didn't carry it very far because I figured it starts to get a little bit unwieldy when you try to generalise. After all, while you can for instance state your result that a sequence of three-multipliers is very efficient, it does restrict you to a power of three multiple of your base clock. So if you want a different multiple, you have to recalculate the possible factors to work out which of the various less efficient options is nonetheless more efficient than the others. Still, I applaud the effort; I'm all for detailed and useful mathematical analysis :3 -- Sorceror Nobody 12:11, 9 June 2013 (UTC)

I actually went ahead and did the table. Then I had to fix my own mistakes... but anyway, the upshot seems to be that larger is better up to N=7, above which it's better to break them up. N=2 is best replaced by N=4 and maybe a toggle. Also, the input repeater loop should be larger than I expected, up to 16 repeaters. --Mental Mouse 12:30, 9 June 2013 (UTC)
 * Uh oh... it looks like 3 toggles beat a 7-mult, 7 toggles beat three 5-mults, and 2 toggles beat a 3-mult, let alone a 4-mult.  The L3 and L5 designs are killers here, possibly linked to the fact that they also use repeater latching. --Mental Mouse 13:18, 9 June 2013 (UTC)

Your clock texture...
I just tried it, but it's reading "16" sometime after midnight, which does not seem to match the table. --Mental Mouse 21:58, 23 July 2013 (UTC)
 * Well, I've just finished the default texture copy of the more accurate version and made that available, so give that one a try, and let me know if it's still misbehaving -- Sorceror Nobody 12:36, 24 July 2013 (UTC)
 * Hmm. It occurs to me that I was not putting it into a JAR file, but subbing it for the clock texture in a texture pack.  This texture pack also has a clock.png.mcmeta file, which seems to refer to the number of frames.  I downloaded the new texture, and will experiment a bit.  Hmm.  Renaming the original clock.png.mcmeta file gets total failure -- purple-and-black.  Putting it back, the new clock reads 12 (white) just after sundown. --Mental Mouse 13:04, 24 July 2013 (UTC)
 * Putting it in a texture -- or rather, resource -- pack is precisely what you're meant to do with it, so I'm not sure what the problem is. As for the rest, the updated file doesn't require any renaming, so you don't need to worry about that kind of thing. The mcmeta should of course be totally left alone; as long as a standard copy of it is present in the /textures/items folder of the resource pack along with the clock, that's all you need -- Sorceror Nobody 16:12, 24 July 2013 (UTC)
 * EDIT: Actually, don't know whether this is an issue or not, but the texture is 32x32. HD textures are, I believe, supported just fine by default (have been since...1.5?) but are you mixing the 32x32 with everything else being 16x16, or anything like that? I don't know whether that would cause problems. I don't see why it would, but you never know -- Sorceror Nobody 16:39, 24 July 2013 (UTC)
 * The pack I'm using is the LAR texture pack, which I think is 16x16. The clock is displaying a 2-digit number on a reasonably-shaped clockface (and I haven't seen any ":00".  Unless you do have the :00 in the texture, I think that means it's fitting in OK. --Mental Mouse 20:19, 24 July 2013 (UTC)
 * Yeah it's fine, there's no :00 because it'd be redundant when it only displays the hour. And also a pain to squeeze into the display. It just has the full time format in the table to make the meaning clearer. So, still having the same problem? -- Sorceror Nobody 21:08, 24 July 2013 (UTC)
 * I think so... I haven't spent enough time with either texture to map out the correspondence, that is, whether it's a straight offset (Minecraft time zones?) or if it's actually on the wrong cycle length. (My meager two observations seem to support the former.) --Mental Mouse 21:20, 24 July 2013 (UTC)   ETA:  Nope, not just an offset.  Where it was reading 12 at dusk, it's not reading 13 at noon. --Mental Mouse 21:49, 24 July 2013 (UTC)
 * How very od- wait. You're expecting 13 at noon from 12 at dusk? It should read 18 at dusk and 12 at noon. With an offset putting 12 at dusk, that'd be 6 at noon. Did you mistype? .-.
 * And in any case, there is simply no way it can be failing to display 12 at noon. Noon is frame 0 of the 'animation'! It's the one time that absolutely must be correct even if everything else is askew! <_> -- Sorceror Nobody 21:56, 24 July 2013 (UTC)
 * Yes, I mistyped "not" for "now". It seems to be going back and forth between 12 and 13 over the course of a day -- mostly 12 at day.  And how is noon the start of the animation, when dawn is tick 1 of the day?  Are you sure this can use the .mcmeta file for another texture file's clock?  For comparision, the file I'm using starts with   and then counts from 0 to 59 before closing the brackets. --Mental Mouse 23:04, 24 July 2013 (UTC)
 * Ah. Bingo. That isn't a correct mcmeta file for the clock, period. The default clock dial would probably be malfunctioning as well, with that. But the bigger issue is actually sort of hilarious: you've got it sampling 60 frames... out of 1200. No wonder it's only giving you 12:00 and 13:00! So, there's your problem. The mcmeta should have no frame parameters or anything in it -- the clock and compass aren't actually animations, you see. They only need an mcmeta file at all so Minecraft knows to break it into frames rather than the game staring blankly at a texture file that's taller than it is wide :P
 * Remove almost everything to leave just {"animation":{}} and it should work. And tomorrow, I'll probably change my download link to include the correct mcmeta anyway so anyone downloading it is sure to have the right thing -- Sorceror Nobody 23:54, 24 July 2013 (UTC)
 * EDIT: As for why frame zero is noon, it just is. That's simply how Minecraft aligns the frames with the time. Same as frame zero for the compass is the needle pointing, iirc, straight backwards -- Sorceror Nobody 00:51, 25 July 2013 (UTC)
 * OK, I made the change, and now the clock is working! Thanks! --Mental Mouse 17:52, 25 July 2013 (UTC)