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)