Template talk:Schematic/Archive 1

Initial Comments and Discussion
This template looks like A good idea, and looks good so far. I do have some suggestions: Good work, in any case! -- 23:39, 21 March 2013 (UTC)
 * Don't use specific real blocks for "input", "output", "solid" and "mobile" (you also might want "transparent").  Create new sprites, and/or make them settable by parameters.  I know I find the gold and lazuli blocks quite distracting, and lapis especially is easily confused for water, which has potential uses in mechanisms.
 * More expanded names as aliases -- for example, "green-wool" or at least "wool-green".
 * A few missing things: bottom slab (both views), and for redstone dust you probably want a side view for looking along a wire, L-junctions to left and right, and at optionally a T- or cross-junction.  Also tracks and minecarts, but I assume you'll get to those eventually.


 * Thanks! Starting to get close to production quality, I think!
 * Although I'm using the sprites of real blocks, I'm deliberately using functional identifiers: e.g., "SB" for "stationary block" instead of GB for "gold block" or something. That way if the community decides to use some other sprite, all that has to change is the sprite position number that SB points to. Everyone has their own opinions on what blocks should be used in circuits -- I'm currently using the blocks from the I've been expanding from initial work in the Redstone Circuits talk pages. Gold blocks were chosen because they most closely matched the typical yellow squares used in schematics, allowing screenshots to look more like the schematics of the same structure. Lapis Lazuli is my personal choice for moving blocks because they're very easily distinguishable from other blocks used in the circuit, etc.
 * Definite possibility. Writing up identifiers is surprisingly tiresome work, though … I've just concentrated on getting done the ones that I'll need to finally tackle the circuit pages (and I finished my short list today! yay!).
 * I can think of at least one mechanism that uses bottom slabs (chicken cookers) -- so you're right, I probably have to add them. And for side-views, I'm mostly limiting the ambitiousness to being able to represent 1-wide structures from the side -- once it starts getting more complicated, it should probably just be displayed as multiple overhead layers (and while dust would require only 11 more sprites, repeaters would require another 64, etc.). All of the side-view schematics I've seen display dust this way, so it's probably okay. But we'll see!
 * &mdash; &middot;  &middot; 00:59, 22 March 2013 (UTC)
 * Good point on the side views. For the solid (Moving, I/O) blocks  I would really prefer seeing a plain yellow square (that is, not resembling a particular block) rather than those distinctive gold blocks, and likewise non-block indicators for the other special roles.  (If nothing else, you're tying up two of the more popular wool colors, and people may want to use those for the diagrams).   Also, it occurs to me that non-generic blocks can be moved too.  Perhaps, along with using "darker" for "covered by a block not shown", we could use "lighter" for "block is mobile"?  For that matter, is it possible to make the "SB" etc. assignments overrideable by parameters?  That would squelch a lot of arguments up front!   -- 03:19, 22 March 2013 (UTC)


 * Well, we disagree on those two points.
 * I think it makes sense for schematics and screenshots to be alike as possible to reduce the number of conventions that have to be learned, so using Minecraft textures in schematics seems right to me, if it can be done without losing clarity (for example, I tried using redstone dust textures for the dust side views and it did not look good, so I went with the standard schematic convention). Except for a little shadow in one of the corners and some stronger edging, blocks of gold are really pretty close to plain yellow anyway:  . As for tying up two of the more popular wool colors, well, they're probably popular for the same reasons I chose them: they provide good contrast to redstone both when powered and unpowered (and green/red is an easy-to-remember metaphor for start/stop) -- it doesn't make sense to deliberately choose two worse colors for something that's going to be used in many many wiki schematics.
 * As for parameters, I don't think it's a good idea to encourage individualization of schematics in the main articles -- some people using blue wool for inputs, some people using stone bricks for structure blocks, etc. We don't want people to have to learn dozens of different styles, they should only have to learn one set of conventions to be able to look at any schematic on the wiki and quickly figure out what's going on in it. Authors would probably have more leeway in tutorials though, but I don't know if we need parameters even for that -- it's probably simpler for someone to just write  if they want blue wool as input A, rather than predefining   or something. (is that what you meant?)
 * I've got two more features to add to Schematic (captions and floats) and I need to make a test page to see how many schematic cells I can get on a page before I start hitting server limits (I'm hoping for 1,000+), then I'm going to ask one of the admins to add the CSS to the main wiki style sheet, and then I plan to request comments (at Community Portal talk, I think). Whether the sprite sheet is too Minecraft-y and whether it should be more schematic-ish is actually already on the list of questions I plan to ask, so maybe we can get a larger discussion about it.
 * Though I disagree, I do appreciate your thoughts on this. Thanks!
 * &mdash; &middot;  &middot; 05:13, 22 March 2013 (UTC)
 * You make good points about standardization. I'm definitely in the "more schematic-ish" camp.
 * Regardless, you do need a few more blocks, some representing issues that kick in for things that aren't purely circuitry: transparent blocks (you could use glass for that), obsidian, (I'd also put in stone) that bottom-slab, TNT.  Another group would be Jack-o-lanterns/glowstone, perhaps torches, plus dirt, farmland, and crops.  Oh yeah -- lava and water.  Good luck on the page limits -- that's the big weakness of BlockGrid.  Possibly you could save a loop by using the names to select individual sprite files?  (E.g., wool-* points the template to Schematic_Sprites-wool.png)  -- 19:14, 23 March 2013 (UTC)


 * Many of those blocks are already on the, I just haven't added position identifiers for them yet (I'm going to concentrate on the circuit pages first). I think I'll put the bottom slab in the empty space under the stone bricks. Torches… 9 sprites… I'll have to think about those. I've got a list of things that could be added to the sprite sheet if needed (another two rows worth), I've added torches to the list (crops, et al., are on it already).
 * The page limits aren't sprite sheet size or loop counts (I'm not using any loops which have hard limits, like #while), it's mainly the bytes included (the very reasonable 2MB ""). How that byte size is calculated is complicated, and doesn't necessarily reflect how many bytes are actually sent over the network. Right now Schematic is adding 600-900 bytes to that count per sprite (depending on whether its a new cell or stacked on a previous), even though each sprite only contributes less than 250 bytes to the actual HTML delivered (and HTTP compression cuts that down a lot). But still, that should be low enough for most articles (I counted over 1,000 sprites currently on one of the circuit pages, I think).
 * The other limits I designed for were avoiding loops with page maximums (I had originally thought the limits were per template call, but they're per article -- they only allow 100 loops per page), secondary includes (I'm used to factoring my code into reusable or functional chunks, but secondary includes can get counted multiple times against the include size), and string functions (which ultradude25 says are slow on the wiki).
 * &mdash; &middot;  &middot; 20:24, 23 March 2013 (UTC)
 * Well, sounds like you're on the case, and delving into site mysteries well beyond my knowledge... the 9 sprites were exactly why I had torches as a "perhaps". Basically I'm thinking this could be useful for all sorts of things.... -- 21:42, 23 March 2013 (UTC)

Actually, you've made me reconsider my use of lapis, at least. You're right, it can look like water. It also doesn't have the edging that gold blocks do, so when there are a few of them together they can blend into each other -- not a problem with the grid borders I'm using in Schematic, but it is a potential problem in screenshots (the edging of gold blocks makes it easy to count them, distinguish blocks at different heights, etc.). I think I'm going to give diamond blocks a try as a moving block -- they're of a similar style to gold blocks, yet easily distinguishable from the other blocks used (iron blocks are too drab though, they tend to fade into the background). (Example) &mdash; &middot;  &middot; 00:45, 25 March 2013 (UTC)
 * Thanks... I think the diamond blocks will be much better. -- 13:55, 3 April 2013 (UTC)
 * "And another thing..." ;-) As I work on the logic gates, I'm getting increasingly unhappy with the "dusty" images for redstone wire.  It's visually very confusing with regard to which ways the dust is connected. -- 15:00, 3 April 2013 (UTC)
 * Try the default size, it doesn't mangle the pixels as much. &mdash; &middot;  &middot; 15:51, 3 April 2013 (UTC)

New separate issue
How do I make small diagrams flow like text? I'm doing the Logic Gates image, and I can get them to float left but they are stacking up there rather than appearing in order. Am I going to need to start in with tables? -- 13:54, 3 April 2013 (UTC)


 * Yes, that's the last problem I wanted to fix before an RFC. I'm using the same classes that image thumbs use to float a captioned schematic left or right, but that defaults to stacking them on top of each other -- which shouldn't be the default behavior for schematics (and uncaptioned schematics are just regular tables, which also stack vertically in the wiki). There needs to be an explicit  instead of , I think. Testing needed.
 * Use tables for now.
 * &mdash; &middot;  &middot; 14:15, 3 April 2013 (UTC)

Transparent Blocks
New problem: If you look at, and compare OR gate E with NOR gate B, you'll see that "darkened" redstone (which I'm using for "covered by a block") looks confusingly like redstone on a top-slab. Top-slabs and glowstone are still the only transparent block with listed names, and glowstone would be seriously distracting here. You might want to ease up on the darkening anyway, but can you also name the glass texture as "transparent", and/or some appropriate abbreviation? BTW, I used "lighter" to indicate I/O locations at lower levels. If you have a better idea for that, please tell me. -- 22:50, 3 April 2013 (UTC)


 * You're right about top slabs and over-blocks look alike. Hmm. For a 3-level schematic though, I wouldn't use the 1-2/2-3 format, I would just layout all three levels as single layers. I doubt a 4-way NOR Gate is important enough to bother with anyway. But the points you raise about the similarity is true.
 * I'm not sure what you mean about glass. Glass can't serve the same purpose in a circuit that a top slab or glowstone could…
 * Using lighter for the I/Os is probably okay, but I think it would get confusing if we tried to lighten all of the previous layer in an upper layer.
 * &mdash; &middot;  &middot; 23:31, 3 April 2013 (UTC)
 * Bah, I lost track of the distinctions about transparent blocks. It really is top-slabs or glowstone for diodes, isn't it?  (Or maybe ice?)


 * For the moment, I'm just trying to do close translations of the schematics, because that's relatively fast, and they'll be much easier to play around with after they're translated. And even if we decide to toss some of the circuits, like you said they'll still be in the history.  I did have another problem, with AND gate F -- I couldn't show the redstone under the mobile block, so I put it in the caption. :-~  -- 01:10, 4 April 2013 (UTC)


 * (...and upside-down stairs...) I agree the whole lower layer shouldn't show through, I just wanted to confirm the placement of that upper-layer stuff.  An idea for the "darker" filter (and perhaps "lighter") -- can you combine the current transparency with a "screen" bitmap, perhaps a checkerboard of 2x2 pixels?  I like dual-layer schematics, because they help make clear how things are stacked.  Your system is a little less powerful there than the old schematic format.  The difference isn't much to trade off for being able to edit them on the wiki, but I'd still like to minimize the loss. -- 02:24, 4 April 2013 (UTC)


 * For now, I've added sprite identifiers for the transparent stationary (gold) and movable (diamond) blocks (SB-u, and MB-u) that are already in the sprite sheet. They're not perfect (maybe make them a little lighter?), but I think they're more intuitive than the "shadow" that the other schematics use. (my goal is that you shouldn't need a symbol key to figure out what's going on in a schematic -- is that unrealistic? dunno.) Give them a try? &mdash; &middot;  &middot; 04:12, 4 April 2013 (UTC)
 * Hmm, I'll need to see how those look in practice. For the other, I'd say "don't need a symbol key at all" would be unrealistic, but you could well manage "only need to see the key once".  Which is way better than the old system.... -- 10:41, 4 April 2013 (UTC)

Request For Comment
First, this template isn't fully complete yet (there's a bunch of sprites on the sheet that don't have identifiers defined yet, but they can be added when needed), but enough is done that people eager to work on the redstone articles would like to get started with it.

My goal with this is to be able to represent any redstone circuit or mechanism -- ideally, without even requiring a symbol key (possible? dunno).

I'd like there to be only a used for both screenshots and schematics. People should be able to look at the two side-by-side and not have to switch mental gears between the two. That's led me to use primarily Minecraft-ish textures in the schematic sprite sheet.

You can see the template in action on some pages where people are experimenting with what it looks like and what it can do:
 * - stress test of 500 cells (warning: very boring and can take 5s of seconds to load when server is busy)
 * - stress test of 500 cells (warning: very boring and can take 5s of seconds to load when server is busy)
 * - stress test of 500 cells (warning: very boring and can take 5s of seconds to load when server is busy)
 * - stress test of 500 cells (warning: very boring and can take 5s of seconds to load when server is busy)
 * - stress test of 500 cells (warning: very boring and can take 5s of seconds to load when server is busy)

Consider and comment:
 * 1) Functionality
 * 2) * Are there any significant omissions on the sprite sheet?
 * 3) Aesthetics
 * 4) * Schematic layout (grid lines, default size)
 * 5) * Sprite sheet
 * 6) Compatibility
 * 7) * Looks fine in: Firefox (mac/linux), Safari (mac, iPad), Chrome (mac, linux),
 * 8) * Unconfirmed (move above when checked): Firefox (windows), Chrome (windows), Opera, etc.
 * 9) Anything else that comes to mind

I have a few issues I'm thinking about, but I'll wait to see what others come up with first.

&mdash; &middot;  &middot; 02:40, 5 April 2013 (UTC)

Server Overloaded by template?
I'm starting to suspect that it may be my Logic Circuits page itself that's overloading the server... the current version is still at. When I try to replace the XNOR section with the stuff at, I get either a blank white screen, or a "Server at Capacity" error. This hasn't happened with the small edits I've made elsewhere.... -- 15:52, 5 April 2013 (UTC)


 * Under normal circumstances the server can handle a few hundred cells of Schematic on a page. My initial stress test was with 1,000 cells and that was timing out occasionally, but not always (if it takes more than 30 seconds to process a page, the server gives up). I haven't seen the 500-cell test time out though, but saving and then rendering an edit may be harder. I've had edits fail with other non-schematic pages before, so it may just be the server, or a bad time (or a combination fo things, compounded by Schematic) -- I've gotten into the habit that anytime the server is taking too long to preview or save an edit I quickly copy my edit text onto the clipboard.
 * Does the wiki not cache articles with templates pre-calculated? That would mean changes can ripple through cached pages, but it would be better than calculating pages every time… &mdash; &middot;  &middot; 17:31, 5 April 2013 (UTC)
 * OK, I'll continue shifting sections to loadPage, hopefully that will help. -- 17:56, 5 April 2013 (UTC)
 * It did help, dramatically. For future reference, I started having trouble with the XOR section, and got stopped almost cold for XNOR.  But now the page seem pretty much done!  -- 20:14, 5 April 2013 (UTC)

Sprite mixup
rd-nsw! appears to be a duplicate of rd-nsew! . -- 19:05, 5 April 2013 (UTC)


 * fixed. &mdash; &middot;  &middot; 22:02, 5 April 2013 (UTC)


 * Also, I've just run into a diagram that uses both sticky and normal pistons. Which led me to discover that while you have separate sprite names for the two, they're visually indistinguishable unless face-on.  May I suggest that you mark the sticky ones with green like MCSim does? -- 23:26, 7 April 2013 (UTC)


 * I do want to do something with them. I can't find pictures of how MCSim marks them, do you have a link or an image? &mdash; &middot;  &middot; 00:44, 8 April 2013 (UTC)
 * Look at the current (old) page.  The design H in the first image shows the green sticky piston.  Note also that the image allows the solid block beneath to show through, which is an issue I've run into several times already (your sprite blocks the whole cell).  Down in "Piston Clocks", the separate 1-tick clock shows both a normal and a sticky piston (though it's not consistent about the solid blocks beneath). -- 02:56, 8 April 2013 (UTC)

Sprite sheet
So, in addition to marking sticky pistons better, here are some other things I'm considering for the :


 * Unpowered redstone torches: are hard to distinguish, they just look like little sticks or something. I'm thinking of increasing their "bulb" size to the same as the powered torches (4x4 circles) but simply of the unpowered dark red color. I.e., more schematic-ish.
 * Redstone dust: I'm now about 50/50 on which is better, the Minecraft texture or the solid lines of schematics. The Minecraft texture is probably more recognizable to people not previously familiar with schematics, but the sparse pixel lines just don't look very good. So I'm thinking of giving solid lines a try and see if we like them.
 * Powered levers: I wanted to make it obvious when a lever is being used as a permanent power source, but I think the current blobs of bright red are obscuring the "lever-ness" of the sprite a bit. So I'm thinking of making the bright red part less prominent.

Thoughts?

&mdash; &middot;  &middot; 01:08, 8 April 2013 (UTC)
 * I agree with you on the unpowered torches and powered levers. For the levers, perhaps a red outline would be better?  For the redstone wire, I favor lines rather than dust -- they could even be "fuzzy" lines, just not as sprawling and speckley as the current sprites.
 * A couple of other suggestions: It might be nice to have a pair of "redstone dot" sprites, the trick would be differentiating them from vertical torches.  You might also consider weakening the ellipses -- when I tried to put them over other cells, they almost completely obscured what was underneath. -- 03:11, 8 April 2013 (UTC)


 * Okay, I've uploaded a new sprite sheet (you may have to reload once or twice). I'm not quite ready to give up completely on the Minecraft texture for sticky pistons, but I did add green borders to the stone base and the edges of the sticky piston extension head. That doesn't allow you to see components underneath unextended pistons, but let's give it a try. &mdash; &middot;  &middot; 04:08, 8 April 2013 (UTC)
 * Initial responses: (1) the redstone lines are very thick and bold compared to the torch and repeater graphics. I'd suggest fuzzing the edges by removing pixels from the edges of the wires, perhaps taking off a pixel's width completely on each side.  (2) The torches are better, but I'd like to see the stick part be thicker, and they really should stick out further in general.  (3) The pistons -- well, I can see the difference, but someone with weak color vision would have trouble.  I'd add more green on the piston edges, if not in the piston body (think "moss stone").  For the transparency issue, in practice you don't need to see components beneath the piston, just a block color.  A few cutout pixels almost anywhere would do that -- around the piston edge, round the corners, or even a blatant "window" in the piston body.  (4) And while I'm making suggestions, it would be nice to have a setting indicator (number or dots) for the repeaters -- reading the position of the slider is pretty squinty. -- 13:53, 8 April 2013 (UTC)


 * Try taking the redstone texture, but drawing a solid 1 or 2px line (depending on where the center is) through it. Might look more natural, while still making a distinct looking circuit. – ᐸ  15:30, 8 April 2013 (UTC)


 * The changes are looking pretty good so far! -- 19:05, 8 April 2013 (UTC)


 * The powered lever against the lime input wool (which will be a common combination) is a bit of a "christmas" color clash, hurts my eyes a bit. I'll see if it grows on me before I try to change it. : )
 * I've made the piston symbols "stackable". They're still pretty obviously pistons, but they allow some of the block underneath to show through. I also removed the green from the stone part of the sticky pistons and strengthened it in the piston extension head (more Minecraft-y, yet more obviously sticky). Some of the up/down sticky pistons still need something though.
 * U25, I tried putting a 2px line through the dust pixels, but there are only a couple pixels that go outside that width, not enough to evoke the Minecraft texture, so it just looks like a messy line. I'll try a plain 2px line (and I messed up one sprite, already fixed for next time).
 * &mdash; &middot;  &middot; 21:27, 8 April 2013 (UTC)
 * The new lines are better -- less dominating, and much more in scale to the torch heads. Of course, they're hidden by piston shafts, but I'm not sure how that could be handled.  Some of the dust lines don't seem to join up very well, notably rd-ew. Is that what you meant by "messing up", or is it just more noticable with the decreased width?  I'd still like to see the torch heads even larger (right now they barely peek out from behind a piston shaft), and torches leaning further out from their block. -- 21:43, 8 April 2013 (UTC)

rd-ew was the one. I've corrected it on my computer. Were there others? &mdash; &middot;  &middot; 23:29, 8 April 2013 (UTC)
 * I just put a couple of redstone "roses" on . I see the following:
 * rd-ew is still not joining on the right, well short.
 * rd-sew and rd-nsew may be a pixel short on the right.
 * rd-sw has an artifact on the right.
 * rd-nsew! and rd-ew! seem to be a pixel short on the left.
 * Some of the verticals are too wide: rd-sew, rd-nsew, rd-sw on the left, their lit versions on the right.  (Compared to the majority.)
 * -- 00:24, 9 April 2013 (UTC)


 * I'm looking at your rosettes and I'm only seeing a problem with rd-ew, all the others look fine. Do you have browser magnification on? (zooming the page with browser commands) -- that messes things up when I do that (with all sprite-based templates, not just schematic). &mdash; &middot;  &middot; 00:57, 9 April 2013 (UTC)
 * Oh my, indeed it does! It seems I was actually down a zoom level -- when I went up to what I presume is zero, all the problems except rd-ew went away.  BTW, I note that the dots are now overpowered for the lines.  Perhaps rather than a box to match the current wires, you could use a box-and-cross?  (That is, knock the corners out of the existing rectangle...)  You may also want to make the side views a bit thinner (not as thin as the top-view wires).  -- 01:17, 9 April 2013 (UTC)


 * I think they either have to be a 6x6 square (as currently) or an actual cross of 2px-wide lines 6px long. If I just knock the corners out, it looks too much like a big redstone torch from above. &mdash; &middot;  &middot; 01:54, 9 April 2013 (UTC)

It has just occurred to me that if naming all those sprites is difficult, perhaps you should define and/or document a "numeric ID" scheme, so that people can use the unnamed sprites by their position on the sheet. Inspired by the Village Blueprints project, which could really use this template. -- 20:06, 11 April 2013 (UTC)


 * Naming the sprites isn't difficult, it just takes time, which I prioritize (along with real life). I'd much rather just finish naming the sprites for real than add any more computation to the template. I've got to finish taxes today, but I could probably finish the identifiers soonish if you need them.
 * The village blueprints were one of the original reasons for the project (though redstone much more), but stairs are insane. Without adding computation to do transformations, stairs would require 480 sprites to show all the possibilities (24 block orientations, 10 materials, 2 view directions). However, they might be worth adding to the sprite sheet -- the extra second or two they might add to the sprite sheet's download time might not be noticed compared to the time the server is taking to compute the template. : ) &mdash; &middot;  &middot; 21:03, 11 April 2013 (UTC)
 * No real rush on my part, as I'm still on redstone circuits. I just stumbled onto the blueprint project and felt pity on their tables of block images.  Yipes on the stairs -- perhaps you, or the user, can "cheat" by layering the material under a partly transparent "stencil" for the position/shape?  Actually, that reminds me of something:  When figuring that "per tile" cost that's producing the page limit, do superimposed types (say, the classic |SB|+|rd-ew) count as one tile or two? -- 22:28, 11 April 2013 (UTC)


 * Actually a stacked tile probably counts as 2*layers-1 tiles (so, 3 tiles for 2 layers), because the  also requires a run through the parameter loop. It's not as computationally expensive as the sprites which also incur wikitext translating, but it adds a little bit.
 * Yes, we can absolutely use a transparent stencil for the stairs. I know exactly how to do that (duh). Whew, that drops stairs down to … 10 + 4 + 1 for overhead stairs. Sideview would require knockouts, so might need 4 more… I'll figure it out. Thanks!
 * &mdash; &middot;  &middot; 00:22, 12 April 2013 (UTC)
 * Glad I could help! On my side, I just got to rail flip-flops, and realized I need a named sprite for the pressure plates.  Of course, then there's the eventual question of how to distinguish top-view pressure plates from wood planks!  (Wood planks as such aren't actually in this diagram, but of course they'll be in the village blueprints.) -- 17:59, 12 April 2013 (UTC)


 * I've added . I'll try to finish all the identifiers this weekend -- they really should be done before we go live (because more people may want to start using the template), and they'll only take an hour or two.
 * &mdash; &middot;  &middot; 21:23, 12 April 2013 (UTC)
 * Oh, but of course you're going to need rails too. Weekend!
 * &mdash; &middot;  &middot; 21:33, 12 April 2013 (UTC)

Um yeah. Also, "SB" is currently displaying as stone brick. I infer that the parameters are less case-sensitive than you'd expected. -- 01:33, 13 April 2013 (UTC)
 * No, I just screwed up. Fixed, thanks! : )
 * &mdash; &middot;  &middot; 02:08, 13 April 2013 (UTC)
 * Thanks for the new named sprites! I notice that in the key, the names of the icons are sometimes flowing to the next line from their image -- you might want to figure something out to stop that.  For the redstone dot... what if you knocked out two or three pixels from each side of the rectangle, to just fuzz the edges a bit?  If that doesn't work, I'd say go for the cross, because right now that dot is in ALL CAPS. -- 19:54, 15 April 2013 (UTC)
 * Another thought: Should there be a ts-u sprite?  I haven't needed one yet, but I can easily imagine the occasion. -- 21:00, 15 April 2013 (UTC)


 * Yeah, I noticed the line breaks too, but  didn't fix it. I think I'd have to wrap each definition in it's own white-space:nowrap span, but I'm not even sure that would work because the sprite span would still be a separate html element from the text. I'll try some things…
 * and dots: I'll try some things…
 * &mdash; &middot;  &middot; 22:02, 15 April 2013 (UTC)


 * I added a transparent sprite for the top slab and made the dust dots smaller so they're not quite as in your face. I also added dots to the lines as well, but I'm not sure about them.
 * &mdash; &middot;  &middot; 00:46, 17 April 2013 (UTC)
 * Thanks on the new sprites. The smaller dot is better, but I'm not wild about the dots-on-lines either, they're distracting, and with the table grid lines, it's not like we need a marker for each segment.  Also, it's probably time to remove the WIP msgbox on the template.  Speaking of msgboxes, we need a Uses_Schematic (or suchlike) template, so we have a standardized msgbox pointing to template docs, style sheet, and reader's guide.  Do you want me to do that when I get back to the pages?   -- 11:16, 18 April 2013 (UTC)
 * Also: If you do the lava and water sprites, the cobblestone generator tutorial becomes an obvious target. -- 13:16, 18 April 2013 (UTC)


 * Yeah, I don't like the line dots at all, but I wanted to try them. I'll remove them soon.
 * I'm not a huge fan of msgboxes -- I think they're distracting and overused (I'm counting five separate notes/messages scattered across this talk edit page). My preference would be that the first schematic in an article (or maybe first per section) includes a link to the guide in its caption. It might be worth creating, say, just to standardize that text.
 * I was going to remove the WIP notices when I finished the identifiers (including lava and water), but I don't see a problem if they're removed before then.
 * &mdash; &middot;  &middot; 17:12, 18 April 2013‎ (UTC)

Page conversion status and summary
So, I've been converting the Redstone Circuits subpages. So far, I've done, , and. The remaining sections are: Latches (which is a monster), and Other Circuits (which is a mess). (But there's at least a whole subpage worth of BUDs, which don't have many schematics.) Given that my real life is happening too, it may be a while before I can finish those. The pages I have done, can go live anytime -- they're down to the sort of tweaks I wouldn't mind being in the page histories.

The schematic system is working fairly well -- at this point I can look at the MCSym schematics and type out the template almost as fast as I can type anything. The sprites are getting steadily better, too. However, there is still a limit to how many cells can be on a page, which I've been dealing with by splitting pages into subpages. (Occasional schematics in a page shouldn't be a problem, but the Redstone Circuits pages are another story.) -- 23:57, 8 April 2013 (UTC)


 * Great work!
 * I'd like to wait at least a week on the RFC (so, April 12th about) before we start putting schematics in "production" articles, give important people a chance to look at it, think about it, comment. But the template and sprite sheet definitely don't have to be perfect, we can keep refining them even while/after updating the circuit pages.
 * I wish the server could handle more templates better. I really did try to make it as minimally-impacting as I could (no string functions, only one subtemplate, …). Sad face. But I think LoadPage is perfectly acceptable as a work-around.
 * Thanks for doing so much work on this and providing feedback!
 * &mdash; &middot;  &middot; 00:57, 9 April 2013 (UTC)

I think it's time to start going live. Probably the best thing is to just move the subpages first, since they don't have targets, then change the loadFile paths, then copy the new category files over the old. Might start on that tonight. -- 21:50, 17 April 2013 (UTC)
 * Arrgh! I started moving subpages (Pulse, Logic, and Clocks are moved, also the guide to Tutorials), but I just discovered a hitch that my editing habits had kept me from seeing before... it seems that loadFile doesn't actually nest -- and Latches in particular uses it two levels deep.  Gonna need to rearrange things there.  (Figuring on merging the intros into the main page, and reducing the loadpages to just designs, all direct children of Latches.  -- 03:03, 18 April 2013 (UTC)
 * I sorted that out, and now we're live! -- 15:04, 19 April 2013 (UTC)

Sideview symbol
tl;dr: Change  to  ?

Currently we use the close bracket --  -- as the symbol for a sideview sprite (e.g.,   for, as opposed to   for ). I initially chose the bracket because it vaguely evoked the idea of "side"-ness (it sort of looks like the side of a block).

But now I'm considering two things that may make it not as good: (1) a bracket looks a little too much like the pipe characters we use to separate parameters, so the brackets make it harder to scan and pick out identifiers, and (2) the bracket is a special wiki character -- I'm not sure that would ever be a problem in a template parameter, but it's something to think about.

I'm liking the dollar sign more now -- it has an upright line which evokes "side" and it has an S for side.

Should we change it? Only a few of Mental Mouse's conversions are sideviews so it wouldn't take too much work to update them. And if we're going to change it, now's the time.

&mdash; &middot;  &middot; 00:34, 12 April 2013 (UTC)
 * The sideviews may be a minority, but many of them are large, and every page has at least one. If I had to switch, I'd probably need to pull them out into Emacs to do an S&R.  Happily, the dash that invariably precedes the ] will make the replace much simpler, but "thas' stil a lotta files".
 * As for $, what it mostly evokes for me is variable replacement, or selecting to the end of a string. Visually, OK, the "vine climbing a pole" thing does match with looking sideways at a circuit, but the right bracket does too.  (On the flip side, the right bracket does itch my "matching parentheses" bump.)
 * If you must change such a thing, please contrive to have both characters working for an interim period -- like I said, the changes will take a while. -- 13:12, 12 April 2013 (UTC)


 * We definitely don't have to change it. I'm just looking for opinions. But if it should be done, it should be done soonest.
 * Ignore for the moment the replacement work (I'll do if it you want). Should it change?
 * And if we do change it, it will probably make it easier to locate schematics that need to be updated if we don't have them both simultaneously -- outdated identifiers will show up as text making it easy to see which schematics need to be updated. (?)
 * &mdash; &middot;  &middot; 15:54, 12 April 2013 (UTC)
 * . For "should", the first question is, is $ itself free of interpretive entanglements?  Not parsed for regexes or anything?  Or at least more "free" than an unmatched right-bracket?  I have to admit, the idea is growing on me, but certainly if we do it, it should be before "going live".


 * As far as "locating schematics", I have no intention of doing this sort of thing by going through the schematics, backspacing over brackets and typing dollar signs! My default routine would be:  fire up an Emacs window on my desktop, then for each page:
 * Open page for editing in Web browser
 * Select All, Copy
 * Paste into Emacs window
 * Search and Replace '-]' with '-$;.
 * Copy-and-paste back.


 * It occurs to me now that Emacs certainly has a web-browser mode, if it can handle the wiki that might make things faster. I made a casual look for a plugin to add search-and-replace to the Firefox text-box, but their search box short-circuited "search" to "Google".  -- 19:41, 12 April 2013 (UTC)
 * or maybe not... the only such thing I could find was w3m, which was described as "can be used as a lightweight web browser", but can't handle the login buttons... or for that matter, the page edit box. Whatever, the method above still works.  -- 20:01, 12 April 2013 (UTC)


 * The idea just kept growing on me too. Think about it a little more, and if it doesn't seem like the right long-term decision we can drop it. It's not like sticking with a bracket will cause us to be hated by future generations…
 * &mdash; &middot;  &middot; 21:27, 12 April 2013 (UTC)


 * You know you can just use JavaScript right?  run that in firebug/firefox console with the editbox open. – ᐸ   21:45, 12 April 2013 (UTC)
 * Ultradude: I did not know.  Thanks for the incantation!  Munin:  Unfortunately, it probably is better, despite my misgivings.  And like I said, if we're going to do it, it should be before launch, which means pretty soon.  By the way: notice the two different uses of $ in US25's code snippet?  That's the other big reason I flinched away from using it here... but if you're sure it's "free" in that context, I'll go along. -- 18:01, 13 April 2013 (UTC)

Well, I've gone and done it. May future generations forgive us!

Let me know if you want some help updating your pages.

&mdash; &middot;  &middot; 00:51, 17 April 2013 (UTC)
 * I gather that ] still works, since the pages mostly look OK. (Discounting something odd with ts-] in the Guide, I'll check that after the conversion.)  Starting S&R campaign now.... -- 13:55, 17 April 2013 (UTC)
 * I think I'm done. The "something odd" above appears to be that the wiki was taking a while to clear out its caches. -- 15:47, 17 April 2013 (UTC)

Style sheet
We need a pair of style sheets for schematic use.... I saw one for writing them that was in user space, but the link got removed and I lost track of it. :-( Munin, do you have it tagged?  In any case, it will need to be updated to account for some of the conventions I've been working out.  But we will also need a shorter one for just reading -- giving the brief cheat sheet, and again explaining the conventions from the reader's point of view.  I'll probably take a shot at that after I finish my first pass through the "Other" circuits file, but if someone wants to beat me to it, I'm fine with that. -- 18:08, 13 April 2013 (UTC)


 * Do you mean a symbol key? Something that explains what all the symbols mean? There's, and a few of the circuit articles duplicate some of it.
 * There should probably be only one symbol key or they'll diverge. Developer notes can be phrased as asides, sidebars, or collapsed tables to keep them from distracting regular readers.
 * Not being a fan of big notices at the tops of pages, I was thinking maybe just the first schematic on a page has a link in its caption to the symbol key, and the rest just carry on, what do you think?
 * &mdash; &middot;  &middot; 18:39, 13 April 2013 (UTC)
 * More or less, but in this case it would be more about the conventions -- Start with "gold for solid, diamond for mobile" etc., but then explain the wool colors, transparency, darkening, and lightening. (Lightening:  block is in that position, but not on the level of this diagram.  Darkening should normally be explained in the caption, but so far I've used it for something in a hole (it was the only thing on that level), but more often for "there is another solid block atop this one".  Also, I'm using ellipses to indicate a repeatable section of extendable diagrams. -- 22:19, 13 April 2013 (UTC)
 * BTW, the page documents the old schematic system.  Having figured out the reason I couldn't find it (it was in user space), I re-found... um, your style guide, whose talk page pointed me to .  This is perfectly cromulent for people writing schematics, and when we go live, it should replace, with the old page moved to something like "MCRS Schematics" and linked by a "See also".
 * However, what I also would like to see, is a mini-version for readers, the "look at the docs once" version. -- 11:49, 15 April 2013 (UTC)
 * On second look, the style guide didn't actually discuss schematics, only screenshots. I have now remedied that a bit -- not a full key, but notes specific to the schematic side of things.  -- 13:37, 15 April 2013 (UTC)


 * Would it make sense to put the cheatsheet right in the Schematics section of the style guide? A short one-sentence introduction to schematics, then a cheatsheet subsection, then an author's discussion subsection? Then we could link right to that section, readers will immediately see the cheatsheet, authors can go further, and it's all in one place? With the cheatsheet right there, the author's subsection wouldn't have to explain particular blocks as much and can just discuss issues and techniques.
 * &mdash; &middot;  &middot; 18:51, 15 April 2013 (UTC)
 * I don't think so... Right now, the style guide doesn't discuss particular blocks as much, it just links to the template (doc), and notes that the template defaults match the notes in the Screenshots section. Which is OK for authors, not so much for readers.  Also, I don't trust links to section headers -- next thing you know, somebody's renamed the section.  (I've been on both ends of that one.) -- 19:46, 15 April 2013 (UTC)

I've got an initial text for the reader's guide at. Still need to put in tile and circuit examples. -- 23:06, 15 April 2013 (UTC)
 * Got some examples and a table of examples up front. BTW, small schematics do not flow with text very well. -- 19:59, 17 April 2013 (UTC)
 * They're tables. You can wrap them in display:inline spans, or you can use the template for individual cells (which are also probably computationally cheaper).
 * &mdash; &middot;  &middot; 20:07, 17 April 2013 (UTC)

Quartz Pressure Plates?
I noticed you added sprites for them (ipp?), and I just recently saw them in the map "the Code". But they don't appear in the man pages, nor in Creative mode. Do you know anything more about them? -- 19:27, 15 April 2013 (UTC)


 * Those are (Heavy), i.e., iron pressure plates (thus,  ).
 * I've never heard of quartz pressure plates. : )
 * &mdash; &middot;  &middot; 21:47, 15 April 2013 (UTC)
 * Oy vey... I went back to the Code and checked, those *are* iron plates, they just blended so perfectly into the map's quartz theme that I assumed they were quartz too.... (And I'd never actually made one.)  -- 01:57, 17 April 2013 (UTC)