Template talk:Schematic

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! --Mental Mouse 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 style guide 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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!   --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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)  --Mental Mouse 19:14, 23 March 2013 (UTC)


 * Many of those blocks are already on the sprite sheet, 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 "post-expand include size"). 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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.... --Mental Mouse 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;Munin295 &middot;  &middot; 00:45, 25 March 2013 (UTC)
 * Thanks... I think the diamond blocks will be much better. --Mental Mouse 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. --Mental Mouse 15:00, 3 April 2013 (UTC)
 * Try the default size, it doesn't mangle the pixels as much. &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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? --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 14:15, 3 April 2013 (UTC)

Transparent Blocks
New problem: If you look at the page I'm working on, 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. --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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. :-~  --Mental Mouse 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. --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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.... --Mental Mouse 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 single set of conventions 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:
 * User:Munin295/Transmission circuits
 * User:Mental_Mouse/Sandbox/Logic_Circuits
 * User:Mental_Mouse/Sandbox/Pulse Components
 * User:Mental_Mouse/Sandbox/Clocks
 * User:Munin295/Schematic/test - 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;Munin295 &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 User:Mental_Mouse/Sandbox/Logic_Circuits. When I try to replace the XNOR section with the stuff at User:Mental_Mouse/Sandbox/Logic_Circuits-XNOR, 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.... --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 17:31, 5 April 2013 (UTC)
 * OK, I'll continue shifting sections to loadPage, hopefully that will help. --Mental Mouse 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!  --Mental Mouse 20:14, 5 April 2013 (UTC)

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


 * fixed. &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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? --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:44, 8 April 2013 (UTC)
 * Look at the current (old) Redstone Circuits/Clocks 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). --Mental Mouse 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 sprite sheet:


 * 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;Munin295 &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. --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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. --Mental Mouse 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. –ultradude25 ᐸ Talk Contribs 15:30, 8 April 2013 (UTC)


 * The changes are looking pretty good so far! --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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. --Mental Mouse 21:43, 8 April 2013 (UTC)

rd-ew was the one. I've corrected it on my computer. Were there others? &mdash;Munin295 &middot;  &middot; 23:29, 8 April 2013 (UTC)
 * I just put a couple of redstone "roses" on User:Mental Mouse/Sandbox. 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.)
 * --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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).  --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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. --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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? --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &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.) --Mental Mouse 17:59, 12 April 2013 (UTC)

Page conversion status and summary
So, I've been converting the Redstone Circuits subpages. So far, I've done Logic Circuits, Pulse Components, and Clocks. 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.) --Mental Mouse 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;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:57, 9 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;Munin295 &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. --Mental Mouse 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;Munin295 &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".  --Mental Mouse 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.  --Mental Mouse 20:01, 12 April 2013 (UTC)