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:Munin295/Schematic/test - stress test of 500 cells (warning: 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)