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?

—Munin295 · · 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.

—Munin295 · · 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?

—Munin295 · · 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?

—Munin295 · · 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.

—Munin295 · · 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.

—Munin295 · · 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.

• 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 (bs?), 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.

--Mental Mouse 03:16, 6 May 2013 (UTC)

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. : )

—Munin295 · · 17:50, 21 May 2013 (UTC)

I see you're simply using bW for duplex i/o. If it's going to be a convention, we should probably have a specific identifier for it. inout? duplexio?

—Munin295 · · 23:31, 25 May 2013 (UTC)

I'd say just duplex -- match the other two. --Mental Mouse 02:39, 26 May 2013 (UTC)

Suggestions[]

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 ×3, ×5, or even ×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.

—Munin295 · · 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.

—Munin295 · · 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.

—Munin295 · · 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).

—Munin295 · · 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)

Can you mock-up a working example? I'm not quite sure I understand the mechanics of what you're suggesting.

Personally, I've completely abandoned making schematics in any sizes except 32px, and I've been changing 16px and 24px to 32px when I notice them.

—Munin295 · · 18:52, 3 July 2013 (UTC)

.thumb table.schematic:hover {
	margin-right: 0 !important;
	-webkit-transform: scale(2);
	-webkit-transform-origin: right bottom;
	transform: scale(2);
	transform-origin: right bottom;
	z-index: 20;
}
div.thumbinner {
	overflow: visible;
}

Hovering over any schematic in a thumb box (captioned) will magnify it. –ultradude25 ᐸ Talk
Contribs 02:37, 4 July 2013 (UTC)

I had to add !important to the overflow to get it to work, but that probably wouldn't be a problem if this was in the wiki common.css.

I think I'd prefer that this be added as an optional feature (maybe by setting a template parameter, e.g., "zoomable=true"). I'd definitely like to preserve the option of adding tooltips in the future (when lua), and there are going to be (or maybe already are) large schematics we won't want to zoom when you hover over them because they'd be too big for some screens. For example, a 16-line double-spaced unary circuit is going to be 528px wide at 16px cell-size, and doubling that will make it larger than your screen, making it difficult or impossible to read some tooltips.

I've lost track of this thread a bit. What problem are we trying to solve again? Sorry…

—Munin295 · · 04:07, 4 July 2013 (UTC)

The hover is just for the mock-up, since it doesn't need any JS. As I said, we would probably have a button (to the right of the caption) to toggle the zoom (using the image you would see on normal thumbnailed images, had Curse's CDN not broken it). The JS can be made to limit it to only 16px and maybe 24px if needed, as well as having it be forced off or on in the template.

The problem is 24px images are a decent readable size for large schematics, but has distortion; and 16px has no distortion, but is too small. This solves that by allowing 16px to be used as a "thumbnail" in place of something that would usually use 24px. –ultradude25 ᐸ Talk
Contribs 04:51, 4 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.

Bottom slab is useful in PEZ minecart dispensers.

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?).

Rails, side view, facing into the viewer.

ra-$ns, ar-$ns(!), dr-$ns(!) pr-$ns(!). Helpful when drawing a single slice of 1-tilable design where all slices are fed by a single minecart with hopper, e.g. super-smelters. Sharfpang (talk) 15:53, 30 January 2019 (UTC)

Scaffolding, at least sideways.

It became an important block for odd-gametick clocks and can transport signal (updates) arbitrary distance upwards and up to 6 blocks horizontally at 1 block per gt. Sharfpang (talk) 11:24, 9 August 2019 (UTC)

Cauldrons and composters

They are important blocks because because they can power things in interesting ways, composters can have a wider range of power stregnth and are useful in farming, and cauldrons could be used in redstone circuits since Java 1.6.1.

All the types of commands blocks

Useful in command-based creations. Sagessylu (talk) 10:45, 4 June 2020 (UTC)

—Munin295 · · 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"?

—Munin295 · · 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)

I'm still not seeing ID's for torches. ETA: And did you ever get those stairs working? --Mental Mouse 13:26, 3 August 2013 (UTC)

You threw tons more stuff at me and I got discouraged. : )

I do want to add rr-$n/rc-$n/rs-$n, plants, arrows, torches, stairs, and fences. Those are needed.

Have you used iron bars for anything? It might make more sense to just replace iron bars with fences, since fences actually have redstone functionality (supporting pressure plates).

For the rest, rather than expanding the sprite sheet to a huge size for rare sprites, I think it makes sense to add functionality to the template to check other sprite sheets. If the template doesn't find the identifier in its primary pos lookup, it checks the secondary pos lookups. But I should wait for lua for that, which might be coming soon.

—Munin295 · · 15:09, 3 August 2013 (UTC)

Sorry about pushing too hard. :-( I'm pretty sure I haven't used iron bars for anything, and I'd totally trade those (and end-on repeaters, for that matter) for fences.

Aside from extra sprite sheets -- If you're willing to accept a lot more stylization, you could probably multiplex fences in the same way as you're planning for stairs -- that is, the "fence lower-half", "fence top", and the top-down shapes as stencils, that would show through different materials. For most of the options, they wouldn't look much like they do in the game, but they'd still get the idea across well enough for a diagram. --Mental Mouse 17:58, 3 August 2013 (UTC)

Okay, I'll try to take another look at the sprite sheet soon. : )

—Munin295 · · 19:29, 3 August 2013 (UTC)

I lied! Apparently the idea of working on the sprite sheet fills me with a sense of despondency. Maybe I'll get interested later. Sorry!

—Munin295 · · 22:56, 26 August 2013 (UTC)

Awww... I hope you regain your enthusiasm over time. You have done great work here. --Mental Mouse 22:22, 27 August 2013 (UTC)

Module[]

Module:Schematic is done and available as Template:Schematic2.

There are some differences from the current template which should be reviewed by people that use it before this is applied.

1. Because it's easier to code, layering sprites is no longer a separate parameter: SB+ra-ew rather than SB|+|ra-ew. This will be fixed on existing templates with a bot.
2. In "fake image" mode, a question mark linking to the schematic help is automatically added. The main issue here is it is not obvious enough that the question mark is not part of the caption. Any ideas for an icon? Preferably one that goes well with the enlarge icon on thumbnails, as I'd like to add that later to allow the schematic to be magnified.
3. Titles can be assigned to IDs using the Module:Schematic/titles table (I did a few for the example on the right). Currently, layers are shown as "upper over lower", but this could easily be reversed to say "lower under upper", if preferred.
4. When only a single cell is specified, it is displayed in a span, rather than a table. Thus, there is no SchematicSprite module. There's currently an issue with it displaying in line with text which I need to resolve (it gets <p>ed on), but basically {{SchematicSprite}} will be made redundant, in favor of always using this template.
5. Performance should be reassessed to see if we need to continue with the LoadBox nonsense. Lua is probably fast enough, but I've noticed that high usage of a module seems to cause it to run out of memory. However, this probably only occurs in situations where the template equivalent would've caused the page to just not load at all, so it may not matter in real usage.
   See Mods/Runecraft and User:Lennbot/Structure Blueprints/Desert Temple 11-15 for examples where this occurs. I need to test if it is merely overhead from having to invoke the Lua engine around 600 times, or if it is the sheer size of the grid module (which has 4 templates worth of functions in it, the only purpose being to reduce the clutter in the "templates used on this page" list, rather than anything to do with performance or usability or anything actually important).
6. Probably some other stuff I've forgotten about, since I initially wrote the module about half a year ago...

–Matt ᐸ Talk
Contribs ⎜ 12:22, 5 February 2014 (UTC)

@Schematic help question mark, adding a dotted bottom border to it makes it stand out quite well from the rest of the caption, but I'm not sure it looks very nice. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 19:43, 5 February 2014 (UTC)

awesome. I had expressed doubts before about whether a lua module would help significantly with the server load problem of the schematic template, but I am now convinced. I just ran some tests with Schematic2 and was consistently able to load over 2K sprites per page within seconds (at 2K it was starting to take some time, so I didn't try higher), where the previous Schematic would start to time out at less than 500 sprites. I tried 1000 2-cell schematics, 200 2-cell 5-stack schematics, 20 50-cell 2-stack schematics, and even 2 1000-cell schematics -- no problem. Some responses:

1) This was my original intent, so great!

2) Maybe just use the question mark commentsprite for now? It'll look better against the white background than here.

3) "upper over lower" seems more intuitive to me.

4) When I use "style = display: inline-block; float: none; vertical-align: text-top;" to get multiple schematic2s to flow horizontally, I'm seeing spacing between them I wasn't seeing with schematic. Same problem?

—munin · · 00:54, 6 February 2014 (UTC)

2. Yeah, that will do for now.

4. The schematics use the thumbnail classes for floating which add margin by default. Set float to none to remove margin, if you don't want it.

–Matt ᐸ Talk
Contribs ⎜ 06:03, 6 February 2014 (UTC)

I plan to deploy this soon if nothing else is brought up. I'll have a bot go through and make the following changes to the existing usage of the template:

1. Replace |+| with +.
2. Remove {{schematic help}}.
3. If either of the above are done, also move |- to its own line. This is a minor style change that I'd like to make. It makes the syntax the same as how tables work, which I think makes it easier to read the template code.

–Matt ᐸ Talk
Contribs ⎜ 04:09, 9 February 2014 (UTC)

I've already started using Schematic2 so I'm happy to see the old ones converted.

I vote no to #3. I personally don't think I would adopt that convention (vertical textual sprawl reduces how much you can see in the editing window). Also, some people are using schematics in their own userspaces and we certainly shouldn't impose stylistic changes on them. Style guide decisions should be a community discussion and I don't see any need to make such decisions now.

—munin · · 04:58, 9 February 2014 (UTC)

I find schematics easier to follow when there's one line of code for each row of the rendered schematic. I'd vote for at least having each |- followed by a newline. -- Orthotope^talk 05:09, 9 February 2014 (UTC)

Alright I'll leave that (user pages wouldn't be edited anyway), just thought I'd mention it in-case it was preferred. –Matt ᐸ Talk
Contribs ⎜ 05:38, 9 February 2014 (UTC)

All done. You should check the positioning of things, one thing I noticed in some places you have floating sprites with a clear right after, rather then just setting the float to none, which will cause extra margins. Let me know if there's any user pages you want converted. –Matt ᐸ Talk
Contribs ⎜ 09:22, 10 February 2014 (UTC)

Yeah, all my user pages need to be converted. I think you may at least need to run the |+| -> + conversion on everyone's user pages.

You mean float=none as opposed to style="float:none;"?

I'll probably just leave them for now, since they all need to be moved back onto the pages anyway, and I haven't quite figured out what to do when there's already a nice screenshot for a circuit.

Thank you!

—munin · · 14:29, 10 February 2014 (UTC)

Yes, because then it sets the tnone class, which removes the side and top margins and reduces the bottom margin (and obviously sets the float to none). –Matt ᐸ Talk
Contribs ⎜ 15:59, 10 February 2014 (UTC)

Layered schematic[]

What's the appropriate way to display a layered schematic? There is Template:Layered blueprint, but I don't see how I can use the schematic sprites in it. I don't really want to use the block sprites with manual rotation, which also don't seem to be too helpful when you want to show a side view for simplicity. RealWormbo (talk) 14:41, 20 January 2019 (UTC)

I actually came here to ask if a template for layered schematics should be created. For now, I think you would just create multiple schematics with the caption explaining what layer it is. - Cherryblossom000 (talk) 07:05, 8 June 2019 (UTC)

Need a honey block (ETA: and fences)[]

I just ventured to start doing schematics for flying machines, and while the design I'm doing now doesn't need it, it occurs to me that honey blocks are also used in such things... and it looks like we don't have a sprite/ID for that. --MentalMouse42 (talk) 11:40, 24 May 2021 (UTC) ETA: Also, it looks like while we have iron bars, we never did put in fence posts, and the build I'm doing actually does use a couple of those. --MentalMouse42 (talk) 11:45, 24 May 2021 (UTC) ETA2: OK, we apparently do have a honey sprite, it's just not mentioned in the help page. That I can fix. Don't know if fences are also undocumented-but-there.

I have added the fences to the documentation. However, there are still some sprites that are implemented but undocumented, and some that are in the spritesheet but not implemented. You can help fill in these gaps. Fadyblok240 (talk) 03:27, 25 May 2021 (UTC)

I gather the schematic itself is in Lua, but I don't actually know where the source for that lives. If you give me a list of the undocumented sprites I can add them to the docs. For that matter, what are the ids for the fence sprites? --MentalMouse42 (talk) 11:19, 25 May 2021 (UTC)

Needs a sprite for campfire[]

I don't see a way to show a campfire in a schematic. Does that even exist? Amatulic (talk) 02:00, 10 December 2021 (UTC)

Add glazed terracotta[]

Suggesting to add at least one colored variation of glazed terracotta for usage in slime/honey block contraptions. Whether should we add all other 15 versions and whether should we use all directional variants (yielding 64 sprites in total) is something I leave open for discussion. — BabylonAS 05:49, 18 June 2023 (UTC)

Only now did I realize that glazed terracotta is present in the template since 2020 🤦🏼‍♀️ — BabylonAS 09:09, 9 August 2023 (UTC)