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)

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)