Talk: SchematicSprite

Max loops?

I think I'm running into a loop maximum of 50 per page, because of my use of #while. Am I correct that if I switch to using #forargs or #fornumargs, I won't hit any page maximums? I think I see how to make that work, using some secondary templates: #replace +s with pipes; when that's plugged into a secondary template call, the template will only see pipes separating parameters and can cycle through them with #fornumargs…. If that works, it might actually make the code easier to follow.

—Munin295 · · 06:06, 8 February 2013 (UTC)

Yes #forargs or #fornumargs are not counted in the loop PP. –ultradude25 ᐸ Talk
Contribs 03:23, 9 February 2013 (UTC)

Okay. I couldn't find a way to #replace +s with pipes ({{!}} doesn't get expanded until later, I think) so I just called a predefined number of parameters with #exploded pieces of the string. A little extra work for the server handling blank parameters, but it seems to have solved the issue. Thanks!

—Munin295 · · 06:33, 9 February 2013 (UTC)

Can you not use |? –ultradude25 ᐸ Talk
Contribs 06:49, 9 February 2013 (UTC)

I couldn't get either of them to work. The replacement occurs, but it doesn't seem to get the template call to interpret the string as multiple parameters, so maybe they get converted to pipes later? You can see some tests I did at SchematicSprite/sandbox.

—Munin295 · · 08:04, 9 February 2013 (UTC)

Memory limits

I'm starting to hit some memory limits (post-expand include size, a very reasonable limit of 2MB — who wants a 2MB article? not me).

Currently, with (1 + 3*layers) <spans> per sprite, each with extensive CSS properties (especially transforms), a single sprite produces about 1-2KB in markup text. A typical redstone circuits article has hundreds of schematic cells, so it would take 100s of KBs worth of markup to convert the images to tables. That seems excessive for a wiki article.

Getting some classes defined in the main style sheet would only cut the markup about in half, and I don't think that's enough. I think I need to back up and punt.

I decided to use image pieces and transforms because it allowed me to use a much smaller sprite sheet than I originally thought I was going to need. But a sprite sheet ideally only gets downloaded once per session, while the markup needed to use such a sprite sheet needs to be downloaded with every page.

If I go back to my original idea of one large sprite sheet (or multiple smaller ones checked for a valid identifier sequentially), with all the block variations explicitly laid out (e.g., 96 repeater variations, 240! stair variations, etc.) using standard /pos notation, I think I can get it down to about 250 bytes of markup per sprite (and half of that is just the img tag produced by File), which means the tables would add only 10s of KBs of markup to an article (which the current images already do, though probably not quite as much).

Is there any way to get the actual uri of an image, so I can use a background-image property directly on a td tag? That would get me down to about 100 bytes of markup per sprite, I think. But testing it produces an "insecure input" warning:

 

Thoughts? Reality check?

—Munin295 · · 18:57, 10 February 2013 (UTC)

Background image url() is disabled in wikitext. The only way to use it is in a stylesheet.

You should see about removing .schematic-sprite-layer's styling, since .schematic-sprite-box's styling seems to work fine on its own.

Creating a test article that uses the template in the sort of way as it would actually be used would be advised. If this is going to be replacing those schematic images, then I think it is highly likely you'll hit PHP's max execution time long before you replace all the images and the page will just not work at all.

If you still want to change your styling to a stylesheet, then do it in your user css and when you're finished I'll add it to the site css. –ultradude25 ᐸ Talk
Contribs 20:30, 10 February 2013 (UTC)

background-postion doesn't seem to be disabled, so I could have a CSS class add an image as a background, and use a runtime-calculated style attribute to position the background. That might work. How dependable are the urls of images? If File:SchematicSprite.png expands now to https://minecraft.gamepedia.com/media/minecraft.gamepedia.com/c/c2/SchematicSprite.png, will it always?

Scaling a background image would require the background-size property, which is CSS3 (IE9+, Firefox 4+, etc.). Would that be a problem?

Alternatively, is there a way to apply a style attribute to the img generated by File? Then maybe I could set it's position relative to a container td without a span.

To put the sprite counts in perspective, between them, {{Blocks}} and {{Items}} display about 300 sprites, with about 400 bytes of markup per sprite (~120KB, although HTTP compression shrinks that down a lot). I can get 15 iterations of the two to load (4500 sprites), but 20 iterations (6000 sprites) sometimes fails (returns blank page). I will do a real test article, but at least this makes me think my punt might be technically possible (about 500 sprites per page, 100-250 bytes per sprite), since I won't really be doing anything those templates don't do.

—Munin295 · · 22:58, 10 February 2013 (UTC)

It's only url() that's disabled. Background-image works fine with anything that isn't using url() (e.g. css gradients). The image urls would only change if you were to move the image.

IE8 and lower barely works with the wiki anyway, and for Firefox/Chrome/Opera/etc. we should only worry about supporting recent versions.

No.

The sprite template is very simple in comparison to this template. Each BlockLink/ItemLink template just needs to replace spaces with -, send it off to BlockSprite/ItemSprite which looks through a single switch for the number to give to the Sprite template with uses simple math to translate the position.

This template has a lot of sub-templates (just looking at the main page shows 6!), which is going to slow it down a lot further. The template is far more complex than the sprite templates, especially since you're doing a fair amount of string manipulation, which seems to be incredibly slow for some reason (as evidenced by the grid template, and the need to move the animation parsing the javascript, and even then the wiki just loading the first frame is fairly slow). –ultradude25 ᐸ Talk
Contribs 00:12, 11 February 2013 (UTC)

Exactly. I'm saying I need to abandon my plans to use transforms and image pieces (and impossible-to-maintain comma-delimited lists) and do this pretty much the same way BlockSprite/ItemSprite do. The sprite sheet will be larger, and thus the lookup switch will also be larger, but otherwise.

I didn't know string functions were slow. I'll have to think if there are good ways to avoid them (so darn useful).

—Munin295 · · 01:48, 11 February 2013 (UTC)

Merge with Template:Schematic

Looking at the parser function, the templates are exactly the same, so this is a duplicate template.

Merging is not as simple as it may seem, the following things must happen:

• The documentation and examples must be merged.
• The sprite ID lists must be moved. The Blobs 01:03, 5 February 2017 (UTC)