Template talk:Schematic

Yep, sprites again.
While working on cobblestone generators, it occurs to me that there's no way to indicate a bottom slab in a top-view. I had also been thinking we'd need arrows, but then I realized we can use HTML entities/Unicode for that. --Mental Mouse 01:33, 21 April 2013 (UTC)


 * I think text arrows are really only good for the cardinal directions, but that should be enough for cobblestone/obsidian generators. But for more complicated water/lava, we'd need 16 direction arrows.
 * Any ideas for bottom slabs?
 * This topic seems like a good place to start a "wishlist" for more sprites:
 * crops (melon/pumpkin stems, melon, sugar cane, wheat, carrots, potatoes, nether wart) -- I think an overhead and a sideview would be enough for each, we don't need to show all the possible growth stages
 * water/lava directions
 * torches (the regular kind)
 * stairs (will necessarily add sprites for planks, bricks, nether brick, and block of quartz)
 * glass panes
 * Anything else?
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 04:41, 21 April 2013 (UTC)
 * Hmm. For the bottom slab, you could emphasize the edge textures and maybe show a bit of highlighting.   For crops, you'll want a common "sprout" texture as well.  Directions:  16 arrows?  Like, north-north-west?  If the game actually tracks fluid direction that closely, then I guess so....   Last night I thought about diagonal minecarts for sloped track, but then I thought it through.  ;-)  Imagine trying to make those play with the table grid!  --Mental Mouse 10:50, 21 April 2013 (UTC)

Well, the origins of the template have just turned around to bite me. When dealing with cobblestone generators, I've discovered a mechanism or two that need "SB" -- an opaque solid block, a transparent block (they're using glass, I'll want to build-test that slabs do work), and a filler block that explicitly can be opaque or transparent. May I request an "any" sprite, perhaps based on the iron block? (That's what they were using.) --Mental Mouse 22:36, 21 April 2013 (UTC)


 * "…can be opaque or transparent…" -- not sure what you mean. If you mean it doesn't matter what kind of block is used, then I'd just use dirt or grass, or just keep using SB to keep it consistent. I'm trying using grass in some of my sideview schematics to show how you'd build them on the ground -- I like it so far.
 * There's a sprite/id for glass if you want it.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:04, 22 April 2013 (UTC)


 * Yup, doesn't matter if it's opaque or transparent. In screenshots and videos, some people do them in glass for visibility.  I'm already using dirt for temporary blocks, needed for building but then removed.  I guess I could use grass, but it feels weird.  Maybe stone brick.  But then, that's the point -- without a standard identifier, everyone picks something different.  BTW, the description for SB and perhaps MB should probably indicate that at least in circuits, they mean opaque blocks.  --Mental Mouse 02:02, 22 April 2013 (UTC)


 * I was probably thinking of this when I added stone bricks to the sprite sheet -- I can't think of any other reason I put it on there (most other blocks on the sprite sheet are there because I thought of a redstone circuit or mechanism that used them). Stone bricks are kind of the go-to block for simple architecture -- easy to make from mining and looks "constructed" -- I see it in a lot of Let's Plays. I guess it's probably a good choice for "there needs to be a block here for structural reasons, but not for redstone reasons".
 * Let's see … "structural block"? no, SB is taken. "construction block"? no, CB for command block. "Building block"? BB, not bad. BB for "building block", defaults to stone brick sprite for starters?
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 07:11, 22 April 2013 (UTC)
 * Why not "AB" for "'any' block"? Stone brick sprite is fine.--Mental Mouse 10:41, 22 April 2013 (UTC)
 * I've added AB with the stone brick sprite.
 * I'm still not sure what to do about bottom slabs. For now, maybe just indicate them in captions or text?
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 16:02, 22 April 2013 (UTC)
 * Thanks for AB. Re; bottom slabs, that's what I've been doing so far.  Incidentally, top slabs can be pushed or pulled from below, which looks peculiar. --Mental Mouse 21:35, 22 April 2013 (UTC)
 * Yep. You can alternate top and bottom slabs in a piston-pushable stack too. : )
 * I like to use slabs instead of glass in circuits where a sticky piston pushes a block up with sand on top of it.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 22:41, 22 April 2013 (UTC)

Hey, I just noticed that your "Note Block" sprite appears to depict a jukebox instead. Also, I'm wondering if we should relax the guidelines on transparent blocks a tad, to this: "If it has to carry redstone, use the top slab, if not, you can use glass". Glass is kinda pretty, it seems a shame to effectively ban it from schematics and screenshots. --Mental Mouse 23:53, 22 April 2013 (UTC)
 * Fixed (mostly). The sprite sheet could use an additional sprite to distinguish note blocks from jukebox sides, but it shouldn't be an immediate problem.
 * It wasn't my intention that top slabs should be used for all transparent blocks, only when you need the dust feature, so if that's the impression the guidelines are giving, yeah, the guidelines should be changed. I'm not aware of a good category name for the blocks that have that feature (glowstone, upside-down slabs, upside-down stairs, hoppers, and technically blocks of redstone I think) so I may have just used "transparent" too broadly.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:27, 23 April 2013 (UTC)
 * OK, sounds good. I'll probably fix it after dinner (also need to mention ts-u in the appropriate place).  A thought:  Should there be an AB-u?  Pro is utility, con is: squintiness, also do we really want to be encouraging dual-level diagrams for more than redstone?  They are much rougher on the page limits, and I'm thinking of mentioning that in the guidelines too. --Mental Mouse 00:44, 23 April 2013 (UTC)

Yup, me again, fresh back from chicken ranching. --Mental Mouse 03:16, 6 May 2013 (UTC)
 * I realized that besides glass panes (noted up top), you don't have fences.
 * Also, it might be handy to have end-on images of repeaters and comparators -- I just ran into a case where I needed it.  (I used the existing side-view sprite and noted it in the caption.)  Admittedly, that was a cross-section rather than a side view, in Tutorials/Egg Farming.  You can probably get away with entirely skipping the repeater delay, thus "rr-$n" and "rr-$s".  (Frankly, I'd rather have numerals or even dots than have to read the slider position anyhow, but whatever.)
 * For the bottom-slab-from above ( ?), we just need something. How about doubling the border width and perhaps rounding the corners by a pixel?  (As if it had rounded edges on top.)  Or if that's too fancy, just make it somewhat darker than the top slab.
 * Another ID rather than a sprite: I've just discovered that duplex I/O isn't half as exotic as I'd thought, since the basic RS latches display it prominently and usefully.  Probably oughta get its own ID.  (IIRC, light blue wool was the original prescription for duplex.)  Also, did you get anywhere with the material+cutout approach to stairs? --Mental Mouse 10:08, 21 May 2013 (UTC)
 * I haven't been working on the sprite sheet. I want to spend what little time I can writing.
 * Technically, whether to have a separate sprite for I/O is a style guide issue, but since you've found an additional reason to have it I withdraw my earlier objection. : )
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 17:50, 21 May 2013 (UTC)
 * I see you're simply using  for duplex i/o. If it's going to be a convention, we should probably have a specific identifier for it.  ?  ?
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 23:31, 25 May 2013 (UTC)
 * I'd say just  -- match the other two. --Mental Mouse 02:39, 26 May 2013 (UTC)

Schematic size
I've seen quite a few schematics using size=24. I would recommend against doing this, because it results in a distorted image. In fact, you should probably change the size parameter to be a multiplier (of 16), instead of a size in pixels; as anything that isn't a multiple of 16 will cause distortion. Then the schematic would default to size=2, instead of 32.

Spritesheet size
The default size of the schematic is 32, but the spritesheet is only 16. This means that the default size schematic requires the browser to support a way to tell it to use "nearest neighbour" image scaling, otherwise the image will be blurry. We have the styling that does that, however it is just a suggestion as far as the browser is concerned, so it is not a reliable way to force "nearest neighbour" image scaling.

The solution to that would be to scale up the spritesheet to 32. This wouldn't increase the filesize (as long as the image is compressed) and then the scaling suggestion will only be necessary for the lesser used size 16. This also means you can use those extra pixels to smooth out things like the wall torch.

Tooltips
Things like multi-layer schematics can be pretty difficult to understand, even when you've read the schematic guide. To help resolve this, I would suggest adding tooltips to each cell, which explains what it represents. At least for the more confusing parts.

For example: 

This may have to wait until lua though, since this template is already slow enough as it is.

Schematic code mistakes
I've seen a couple of common mistakes with schematics that have been written, so I think it'd be best if the template could handle them properly.
 * |- on the last line. Causes an empty cell with no height, so it looks like an extra 1px of border on the bottom of the first row. Should be ignored entirely.
 * Not enough |'s to make enough cells to go to the end of the row. Causes a blank white space with no borders. Should automatically fill in the necessary cells so there are no gaps.

Again, this will probably need to wait for lua.

–ultradude25 ᐸ Talk Contribs 06:20, 22 May 2013 (UTC)


 * Thanks!
 * The only time I've seen distortions at size=24 is when I'm using browser magnification, and that causes distortion with all sizes. But the distortion at size=24 is worse and we can't tell people not to use browser magnification so this is probably a good suggestion.
 * I didn't realize increasing the sprite sheet size wouldn't make the file size huge. I'll definitely look into that. Mental Mouse wants me to get back to work on the sprite sheet anyway. : )
 * Tooltips would definitely be a useful addition, but I'd rather just fix author mistakes than add more complexity to the template. : )
 * I'm not confident that lua is going to be a solution for Schematic. The tests done on wikipedia seems to indicate speed increases of &times;3, &times;5, or even &times;8 for some applications (mostly string handling, I think) -- but the lua timeout is 10 seconds rather than the current 30 seconds, so it might only be a marginal improvement (in terms of how many schematics we can put in an article -- the user experience will definitely be better), not the order(s) of magnitude we really need. But I'll definitely start experimenting with it when it arrives.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 16:34, 22 May 2013 (UTC)
 * Drat... size=32 makes a lot of the schematics seriously overpower their text, and some of them quite big. --Mental Mouse 12:54, 23 May 2013 (UTC)


 * Could the sprites be cropped a bit, while still being recognisable? –ultradude25 ᐸ Talk Contribs 22:30, 23 May 2013 (UTC)


 * I don't like the idea of cropping the sprites. Before that, I think I would consider adding a separate size=24 sprite sheet. That would mean downloading two sprite sheets for most articles (the current one is <70kB), but that shouldn't be a problem for most users and they'll get cached anyway, right?
 * How bad are the 24px distortions you're seeing? I only see them with browser magnification and they're barely worse than the rest.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 23:31, 23 May 2013 (UTC)


 * What would be different with the 24px sheet? It'd still have the sprites cropped?
 * The distortions are apparent on anything that isn't a solid colour, which is everything. Looks at the edges of the gold block, and the redstone torch on the repeater for the most obvious ones. –ultradude25 ᐸ Talk Contribs 00:44, 24 May 2013 (UTC)


 * Ah, well personally those distortions don't bother me at all (I had to get up close to the screen and squint to see what you were talking about). As long as you can see what component it is, it's probably fine.
 * A separate 24px sprite sheet would mean the browser wouldn't have to do any scaling to display a size=24 schematic (which is turning out to be as convenient a size as 32). Or rather it would move the scaling to the image editor used to produce it (GIMP, in my case). But I've just tested it and it either gives the same distortions with no interpolation, or it just makes it fuzzy, so: not a solution.
 * Mental Mouse, for large schematics which are overpowering the text, consider moving them to float=none Loadboxes under the paragraph or section, instead of regular schematics or floated-right LoadBoxes. They're not so bad there, so maybe they could go back up to size=32.
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 01:29, 24 May 2013 (UTC)


 * Maybe my screen just has poor pixel density (it is only 1080p after all), but the distortions are really noticeable to me, without having to go close to the screen.
 * I don't think the cropping will really work. For the more simple sprites you can shave off some pixels in the middle or spacing around the sides without affecting the look too much, but for more detailed sprites (like minecart tracks) I really don't see it working. Instead, I'm wondering if we could get rid of the nearest neighbour scaling for 24px (and have the spritesheet scaled up to 32px). It looks slightly blurry, but you don't loose entire rows of pixels, so it looks more readable to me. –ultradude25 ᐸ Talk Contribs 02:02, 24 May 2013 (UTC)


 * Hmm. For size=24, nearest-neighbor looks much better than blurred interpolation on my screen (1920x1200). We may need a tie-breaker. : )
 * Interpolation makes everything fuzzy. No more crisp edges at all on any of the sprites. The schematics look like they're underwater or something (to me).
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 04:02, 24 May 2013 (UTC)


 * http://matt-russell.com/images/sharex/2013/SS_05-24_02-56-58PM.png
 * To me, it only looks blurry on the transparent edges, mostly noticeable on the wire. Which I still think looks better than the entire image having distorted pixels everywhere.
 * Either way, it'd be better to avoid size=24 as much as possible. –ultradude25 ᐸ Talk Contribs 05:01, 24 May 2013 (UTC)
 * Drat, but losing the 24-pixel option sucks -- it really does fit better for moderately large schematics. And I assume Munin's not interested in hand-tweaking a few hundred 24-pixel sprites. ;-~ --Mental Mouse 02:17, 26 May 2013 (UTC)
 * Also, regarding "Not enough |'s to make enough cells to go to the end of the row. Causes a blank white space with no borders." I consider that a feature!  I'd actually like a way to (controllably) do that at the start of a line too, and maybe even within a schematic. --Mental Mouse 02:48, 26 May 2013 (UTC)


 * If that's a feature then the background needs to be removed, because you get a white background even though there's no cells. I think it just looks messy having parts of the schematic missing. –ultradude25 ᐸ Talk Contribs 04:00, 26 May 2013 (UTC)
 * No, it "looks like" the schematic is laid on a white background, with the grid neatly trimmed around the schematic. As opposed to being laid on pieces of oversized graph paper....  The old MCSim schematics also had odd-shaped circuits, and many or most of those had no surrounding grid at all. --Mental Mouse 10:43, 26 May 2013 (UTC)

While working on the schematic module an idea came to me to help with size issues. What if we allow the schematic to be zoomed? Then 16px would be usable, hopefully in place of 24px.

Implementing zooming is actually stupidly simple. Using the CSS scale transform, you can make the entire schematic larger, and thanks to transforms not changing the space something takes up, it doesn't cause any page movement. This could be implemented purely in CSS using hover or something similar, however it's probably better for there to be an image under the schematic that you can click, which would use JS to toggle the zoomed class. Here's an example. –ultradude25 ᐸ Talk Contribs 15:57, 3 July 2013 (UTC)

Sprite sheet v2.1
Sprites that need to be added:


 * Plants
 * brown mushroom, carrots, crops (i.e., wheat), flower (i.e., dandelion), melon, nether wart, potatoes, pumpkin, red mushroom, rose, stem (melon/pumpkin), sugar cane (top and side sprite for each, full grown only)
 * cocoa pod (4 overhead orientations, 3 side views)


 * Arrows
 * 16 directions, for water and lava flow
 * I'm thinking a 50%-opaque black arrow with 50%-opaque white border (should show up well against almost everything)


 * Torches
 * same orientations as redstone torches (but only one state)


 * Stairs
 * materials (sandstone, bricks, etc.)
 * "darker" sides and corners (to indicate the "step" portion of the stairs in overhead, or further portion in side view)
 * white "knockouts" for side views


 * Fences
 * 16 overhead variations, 4 side view variations


 * Jukebox
 * side view (note block sprite with a shaded slot near the top)


 * Bottom Slab
 * … still not sure about this. I'll try some things.

Anything else? That's about 3 more rows of sprites, but I might go to 4 if it's a better fit. If I also increase the sprite size to 32px, that'll about double the file size I think (but it gets cached, right?).

&mdash;Munin295 &middot;  &middot; 00:00, 26 May 2013 (UTC)
 * For plants, I'd add a generic "sprout" top and side. I'd also still like to see end-on repeaters and comparators, though they shouldn't need settings.  (That is, "rr-$n", "rr-$s", "rc-$n" and "rc-$s").
 * Will the fences have separate sprites for their upper "half-block"? Of course, adding fences opens the gate for their kin, each of which does have unique features.   For the record, the list IIRC is: fences (cheap, 1.5 high), glass panes (lighting, looks, 1 high, fragile), iron bars (tough but 1 high), cobblestone walls (1.5 high and tough, but block vision), and nether brick fences (tough, 1.5 high, and you can see through them).  --Mental Mouse 02:08, 26 May 2013 (UTC)


 * Well, what's needed right now? A sprite sheet that can do everything would be insanely huge. Iron bars and fences would cover the two basic sizes, do we need others right now?
 * What could a generic sprout indicate that a specific plant couldn't? (unless you mean melon/pumpkin stem, which I've added to the list)
 * Also, visually, how would you differentiate "rr-$n" from "rr-$s"?
 * &mdash;Munin295 &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 03:08, 26 May 2013 (UTC)
 * No, we probably don't need all of the ur-fences right now, I just wanted to note the issue.
 * The generic sprout would be for where you just want to indicate that something is planted there, and it doesn't much matter what. And wheat, carrots and potatoes all start off with similar sprouts...
 * And yeah, end-on repeaters may not need two separate sprites, just something to cover the rare case like that egg farm I drew up: There, the repeater settings are shown properly in the top-down plans of the egg room, but a cross-section of the middle shows how the water pen and the egg room fit together.  --Mental Mouse 11:03, 26 May 2013 (UTC)