Module talk:Sprite

Can the module be set up to not wrap the space between the sprite and the text? It looks terrible wherever it wraps. –KnightMiner ^t/_c 03:01, 17 March 2015 (UTC)

It does? It uses padding instead of a space so the icon should stay next to the text, while still allowing the text to wrap. –Majr ᐸ Talk
Contribs 10:26, 19 March 2015 (UTC)

In theory it shouldn't, but it still wraps in tables, refer to Superflat (if you remove the nowrap class I added in the row "Bottomless Pit"). Also, the module does set the text part not to wrap, just not the whole thing. –KnightMiner ^t/_c 16:42, 19 March 2015 (UTC)

I guess I'll just throw a nowrap around it for now... really need to find a non-garbage way to do that, and allow text to wrap next to, or around the icon.

Ideally, wrapping would work something like this: [[Grass Block|👁 BlockSprite grass-block.png: Sprite image for grass-block in Minecraft
Grass
Block]]. –Majr ᐸ Talk
Contribs 13:47, 24 March 2015 (UTC)

Can the nowrap class be moved inside the square brackets for internal links? Otherwise it breaks link trailing, which is used in a few cases to skip setting of a title (such as on {{gameplay}} for Renewable resource). –KnightMiner ^t/_c 15:35, 12 May 2015 (UTC)

I don't see why not. –Majr ᐸ Talk
Contribs 15:45, 12 May 2015 (UTC)

Once last thing I just thought of, if you set white-space:normal in the .sprite-text class, it allows wrapping between words without wrapping on the sprite. It a little less garbage of a solution as wrapping still exists next on the words, just on on the sprite. (example:
Grass Block). –KnightMiner ^t/_c 15:55, 12 May 2015 (UTC)

I think we should merge {{BlockSprite}}, {{ItemSprite}}, {{EntitySprite}}, and {{EnvSprite}} with {{Sprite}}. I also think we should merge their link variants, including {{BiomeLink}}.
~From Contrapple 👁 Image
00:55, 24 March 2015 (UTC)

May I ask why? It seems like a lot of work for little gain. Merging would require merging the sprite sheets (which would lead to file caching issues, as well as renumbering the hundreds of IDs), images with variants in each type (for example, cauldrons) would produce the same thing, and all previous usages would have to be updated due to the ID changes.

Also, this talk page is generally for discussing the Module:Sprite rather than its usage, merge requests usually belong on one of the talk pages the merge is being proposed to, with optional links from the other talk pages. –KnightMiner ^t/_c 01:25, 24 March 2015 (UTC)

I put it here because doing so would mean editing this page. As for why they should be merged, I do not think there needs to be a distinction between the different types, they are all pictures of the block, item, etc. The only difference is the category, which isn't necessary and would probably use extra memory (I don't know how Lua works but I would think that removing if statements would use less memory).
~From Contrapple 👁 Image
01:40, 24 March 2015 (UTC)

It actually uses less memory, though I doubt it is notable, due to the other features to make it more efficient (specifically, the module is only told to load the IDs and images it actually is using, and the IDs are only loaded once per page, thus if a page only uses one sprite type, it only needs to load the sprite sheet and IDs for one type). The reason for the distinction mainly goes back to when sprite sheets were used in game, allowing them to be uploaded directly, but it also allows the convenience of editing, if the sprite sheets were combined the image would be at least three times as large.

Another major problem with merging all types is new sprite sheets cannot be added easily without breaking old usage due to filesize cache. Also, this module is used on templates besides those you listed, some of which you would not want within the main lists (for example, {{schematic}} and {{Mods/Aether/Link}}). So while there does not "need" to be a distinction, it makes things a lot easier. –KnightMiner ^t/_c 02:04, 24 March 2015 (UTC)

Well I agree that the templates you provided are more different, but I would not be able to understand the module without pseudo code.
~From Contrapple 👁 Image
13:16, 24 March 2015 (UTC)

Module:Sprite already handles all of the heavy lifting for the Sprite templates and modules; the other modules are little more than wrappers that set their own data (for example, {{EnvSprite}} contains the code {{ #invoke: Sprite | sprite | settings = EnvSprite }}, which runs Module:Sprite and tells it to load settings from Module:EnvSprite; Module:EnvSprite itself only contains an array with some general settings about the EnvSprite sprite sheet and loads Module:EnvSprite/IDs, which contains another array with the IDs associated with names for the sprites in the sheet). These could all be merged together, but all merging would accomplish is moving all of this information onto a single page, in a massive array that would be much more difficult to maintain than the current separate arrays. Any performance gains would also be negligible and would be related almost entirely to the fact that separate pages would no longer have to be loaded for a given sprite sheet.

If you're really looking to improve performance, I would look instead at all the string concatenations ('foo' .. 'bar', which, when run, would give 'foobar'), since concatenation in Lua is somewhat slow and Lua strings are immutable (which means every time you change a string and store the changed value back to the same variable, Lua actually creates a copy of that variable, and all the old copies hang around until the next time it runs the garbage collector). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:30, 24 March 2015 (UTC)

I notice that when you substitute {{sprite}} or a similar template, you will display 👁 Unknown sprite image
. However someone might want to be able to substitute it so they can use it in signatures.71.212.10.80 16:19, 26 April 2015 (UTC)

The substitution result may be too big to be allowed in signatures anyway. — 👁 Image
NickTheRed37 (talk|contributions) 17:52, 26 April 2015 (UTC)

The code is not very long, and adding support for substitution is a easy thing to do (by simply adding {{{|safesubst:}}} to the templates that call it). The problem is instead that template requires Widget:FileUrl to function, as otherwise MediaWiki will not allow files to display. While that issue is fixed by CSS on the older sheets, there still is the additional issue that we would now be using the sprite sheet without knowing where it is used, as CSS does not add file links. This would mean should the sheet change (as it is going to), there would be no way to update the old usages. I suggest instead using individual images from {{grid}} if you need a specific flair of that type. –KnightMiner ^t/_c 20:37, 26 April 2015 (UTC)

I think there should be a way to display rectangles as opposed to squares. The way to do this without messing up current usages would be to add a paramater for the hight (in pixels). This value would default to {{{size|16}}}.71.212.10.80 20:37, 19 May 2015 (UTC)

There's no technical reason it can't support rectangles, but I don't see the point in adding a feature we don't have a use for. –Majr ᐸ Talk
Contribs 01:25, 21 May 2015 (UTC)

Well we would only do it if necessary ( maybe in th future) 71.212.10.80 22:40, 1 June 2015 (UTC)

We have gotten many sprites that have never been used or are on the wrong sprite sheet, especially on {{BlockSprite}}, and many redundant aliases which would be nice to remove, and it would be nice to be able to create a list containing those. One idea would be changing

if not pos and not mw.title.getCurrentTitle().isSubpage then
 category = '[[Category:Pages with missing sprites]]'
end

to

if not pos and not mw.title.getCurrentTitle().isSubpage then
 category = '[[Category:Pages with missing sprites]]'
elseif type( pos ) == 'table' then
 pos = pos[1]
 category = '[[Category:Pages with deprecated sprites]]'
end

which allow detecting individual names marked as deprecated (marking would be done simply by surrounding the id with curly brackets, as that was a bit simpler then actual containing a keyword in the table). Since numerical ids are generally avoided, that would match nearly all cases of deprecated sprites ID, and will match deprecated aliases as well.

On a related note, it might be relevant to add an optional category (enabled using the settings pages) to mark pages using numerical ids when string ids are available. –KnightMiner ^t/_c 17:34, 25 May 2015 (UTC)

Edit: Line 162 should also be changed from pos = line:match( '=%s*(%d+)%s*,?$' ) or '' to pos = line:match( '=%s*%{?(%d+)%}?%s*,?$' ) or ''. –KnightMiner ^t/_c 19:42, 27 May 2015 (UTC)

In addition to your curly-brackets idea – which sounds good – would you be able to do a trick like this, for instance:

['gear'] = {71},
['71'] = {71},

to be able to put the category on numbered ids?

– Sealbudsman (Aaron) 👁 Image
^t/_c 18:57, 27 May 2015 (UTC)

Unfortunately, that would not work with the way the module is set up, as any numerical values skip processing through the names table (numbers are simply sent to the position math as is instead). Instead, the only way to have a sprite number be deprecated would be using a separate "deprecated IDs" table, so this plan would really only work assuming pages using the template don't use numerical IDs (which we have been avoiding as that is the purpose of the names, hence my comment about a category for pages using numerical IDs) –KnightMiner ^t/_c 19:34, 27 May 2015 (UTC)

Hm. What if in p.sprite(f), instead of having:

if tonumber( args[1] ) then
 args.pos = args[1]
else
 local default = {}
 ...
 local pos = ids[id] or ids[mw.ustring.lower( id ):gsub( '[%s%+]', '-' )]
 if not pos and not mw.title.getCurrentTitle().isSubpage then
 category = '[[Category:Pages with missing sprites]]'
 end
 args.pos = pos
end

we were to rearrange it like so:

local default = {}
...
local pos = ids[id] or ids[mw.ustring.lower( id ):gsub( '[%s%+]', '-' )]
args.pos = pos
if not pos and not mw.title.getCurrentTitle().isSubpage then
 if tonumber( args[1] ) then
 args.pos = args[1]
 category = '[[Category:Pages with sprites with numeric IDs]]'
 else
 category = '[[Category:Pages with missing sprites]]'
 end
elseif type( pos ) == 'table' then
 args.pos = pos[1]
 category = '[[Category:Pages with deprecated sprites]]'
end

It would make it look through the table first. This would be an acceptable a performance hit, right? Especially considering we're discouraging the use of numeric IDs?

– Sealbudsman (Aaron) 👁 Image
^t/_c 20:15, 27 May 2015 (UTC)

Roughly that would work for the deprecation, though note that not mw.title.getCurrentTitle().isSubpage is to prevent from adding the category on translation pages, so it would instead need to be moved to a separate "if" function to allow the numerical positions on subpages. Also, since we generally don't use numeric IDs (except in places where those are the only IDs, which skips this code entirely), I doubt it would affect performance too much.

One thing to note though is that if we are advising against numerical IDs with a maintenance category, then it would be redundant to mark them for deprecation as well, as both cases would require them being fixed. That being said, it would really only make sense to either allow deprecation of numerical IDs, or to advise against all numerical IDs (basically meaning if your code is used, we would leave out the category for numerical IDs). –KnightMiner ^t/_c 22:19, 27 May 2015 (UTC)

like this?

local default = {}
...
local pos = ids[id] or ids[mw.ustring.lower( id ):gsub( '[%s%+]', '-' )]
args.pos = pos
if not pos then
 if tonumber( args[1] ) then
 args.pos = args[1]
 category = '[[Category:Pages with sprites with numeric IDs]]'
 else
 category = '[[Category:Pages with missing sprites]]'
 end
elseif type( pos ) == 'table' then
 args.pos = pos[1]
 category = '[[Category:Pages with deprecated sprites]]'
end
if mw.title.getCurrentTitle().isSubpage then
 category = ''
end

If we leave in both 'deprecated sprites' and 'numeric IDs' categories, we can do the immediate job of deprecating certain sprites like colored wood, etc, and leave the idea of deprecating all numeric-ID sprites until later. Though I suppose it would be easy enough to leave out the 'numeric IDs' category line (line 8) until later as well. – Sealbudsman (Aaron) 👁 Image
^t/_c 22:18, 1 June 2015 (UTC)

That code looks just about good to me. It might be slightly faster to move "args.pos = pos" to an "else" statement at the end of the first of the "if" statement, though I don't think it is too much of a efficiency drop otherwise. (since I cannot make changes to the module, it might be nice to ping Majr so he can state his opinion/add the changes).

As for the numerical thing, I agree if we are not planning on deprecating them at this time that it would be best to leave out the category for now, adding it would simply be a one line change later if requested. –KnightMiner ^t/_c 01:26, 2 June 2015 (UTC)

KnightMiner's simple idea of deprecating sprites seems fine.

I would consider numerical IDs to be deprecated entirely. They were only implemented for compatibility with the old sprite template and really shouldn't be used. –Majr ᐸ Talk
Contribs 08:53, 10 June 2015 (UTC)

Should we change module to Categorize numeric Ids, sweep through the wiki and change them, then do this? – Sealbudsman (Aaron) 👁 Image
^T/_C 18:48, 15 June 2015 (UTC)

I don't think that would be too necessary, as we may as well fix both deprecated ID types at the same time (and really in both cases I can rig up my bot to fix the IDs) –KnightMiner ^t/_c 20:07, 15 June 2015 (UTC)

I say go for it. – Sealbudsman (Aaron) 👁 Image
^T/_C 20:14, 15 June 2015 (UTC)

@Majr: with the code in [[Module:Sprite2]] as planned to replace the code here, the deprecation would likely require using an additional parameter in the sprite data with a name like "deprecated". I would add it to the second module myself, but I would prefer the feature gets full added by adding the proper javascript for the sprite editor to support it as well, so can you add that there? My suggestion for that would be some form of deprecated button on the side of a name, which could also change the background color of the sprite, or simply highlight the name if only one name for that sprite is deprecated. –KnightMiner ^t/_c 23:43, 11 August 2015 (UTC)

Deprecating an entire image would be fairly easy, as the button could just be added to the image's tooltip menu. Names on the other hand are more difficult. I don't like having button clutter on each name, which is why names are removed by blanking them rather than having a delete button next to each one (my original implementation), especially with an uncommon action like this which would be much more suited to being buried in a menu somewhere, rather than presented as a primary control. I'm currently thinking of using a "tool" format, where you enable a deprecation tool to mark names as deprecated by selecting them. –Majr ᐸ Talk
Contribs 03:00, 12 August 2015 (UTC)

Just thinking of how to style the deprecation seems complicated, as we would have to check all of a sprite's names to determine if the entire sprite is deprecated, or just one name. Though the main reason I am wanting deprecating by names is to remove the excessive aliases for certain sprites, of which some aliases are simply a speculative name or a name from before it was known.

The tools menu seems like a pretty good solution to remove clutter of less common actions. It could also be useful as a shortcut for some other actions, such as I find it rather annoying to use the drag and drop move for sections, so a move to section button would be useful. –KnightMiner ^t/_c 22:13, 12 August 2015 (UTC)

I think there should be animation:

• {{{pos}}} and {{{text}}} can be animated
• {{{size}}}, {{{sheetsize}}}, {{{scale}}} and other parameters related to the icon using a number for the frame, except defaultpos (for example, {{{sheetsize2}}} would be used for the sheetsize in the second frame).
  • Anything without a number will be the output for frames in general, but number ones will override this.
  • Any numbers greater than the number of frames (which is determined using pos) will be ignored.
  • If ID's are used, they can also be animated.
• {{{link}}} cannot be animated.

Example

{{BlockLink|id=Sandstone;Red Sandstone|Talk:Red Sandstone|Sandstone}}

Would produce

👁 Image
Sandstone👁 Image
Sandstone

Usage

Schematics that show redstone circuts in their on state and thier off state. 71.212.10.80 21:13, 4 June 2015 (UTC)

I really only see the sprite as needed for animation, as the rest would simply cause text bobbing issues. Though, if the only usage is for redstone circuits, the only thing that really needs animation support is {{schematic}}, which could easily be suggested there. –KnightMiner ^t/_c 17:48, 5 June 2015 (UTC)

It looks like [[:Category:Pages using sprite positions]] is down to just talk pages and sandboxes. Is there a further plan? – Sealbudsman ^talk/_contr 14:58, 15 October 2015 (UTC)

Removed tracking category and special handling for numbers. –Majr ᐸ Talk
Contribs 03:00, 29 October 2015 (UTC)

Can the maintenance categories be removed for user and talk pages? The reason is that both of those pages often will have misuses/outdated uses of the template. In the case of talk pages should not really be changed later even if it has such errors, and for user pages they really shouldn't be edited by people other than that user. –KnightMiner ^t/_c 02:28, 29 October 2015 (UTC)

👁 Image
 Done –Majr ᐸ Talk
Contribs 03:00, 29 October 2015 (UTC)

Can at least the deprecated sprite parameter be added to subpages which are not translations? It should be easy enough using {{Translation category}}. I am currently hesitant to remove any deprecated sprites as I have no idea if a subpage (such as one of the block state or data value tables) uses it. –KnightMiner ^t/_c 01:42, 26 February 2016 (UTC)

👁 Image
 Done. Not sure how much expandTemplate will lower performance, but there shouldn't be many sprites adding categories anyway. –Majr ᐸ Talk
Contribs 02:54, 27 February 2016 (UTC)

The documentation for {{BlockGrid}} intentionally has a missing sprite, but is in Category:Pages with missing sprites. Can editors have the option to cancel the categorization? The Blobs^{👁 Image}
18:43, 7 February 2017 (UTC)

👁 Image
 Done. –Majr ᐸ Talk
Contribs 23:10, 7 February 2017 (UTC)

When using one of the link templates, the default is to go to the linked value. Unfortunately this causes issues when the linked page by necessity is (or should be) a disambiguation; in particular this is a problem for {{EffectLink}} (discussion). It also causes issues for when the ID doesn't correspond with a logical page (e.g. the "old absorption" sprites). I know that it is possible to manually specify the link, but IMO it would be better if the default is useful.

I think it would be possible to fix this by adding an optional link value to the IDs pages that specifies the default link for that sprite (rather than just defaulting to the ID of the sprite). For instance, on those effects it would specify a link as Status effects#effect. I don't think this would be too hard to implement (but I am unable to actually change this template myself and lua isn't exactly my forte). I've put in some sample data for effects (hopefully this doesn't cause issues), though. --Pokechu22 (talk) 03:25, 31 December 2017 (UTC)

Sample data is probably best left on a user page or in a code block rather than the main space.

As for the idea, there is no need to make any changes to the module or the data, it already supports a link prefix keyword to set a prefix to the links. I set the prefix for effect sprite to "Status effect#" so sprites should now properly link there now. –KnightMiner ^t/_c 05:52, 31 December 2017 (UTC)

I know that sample data is best in a code block/user page, but I felt like the solution I was going for was the best at the time so putting it in there seemed reasonable.

I saw the linkPrefix thing but assumed it was intended for namespaces; didn't think to use it for that. That does seem to work here, but I still think my idea has merit as linking for other things could benefit from it (e.g. the particle versions which are currently not useful with EffectLink). --Pokechu22 (talk) 06:39, 31 December 2017 (UTC)

Ping Majr, since you would have the most to say.

The documentation feature of this module is currently causing the template expansion size to be exceeded on {{InvSprite}} where there are about 2,400 different sprite names. There is a temporary fix in place by circumnavigating {{documentation}} entirely, but for a more permanent fix we should reduce the wikitext output. I have two potential solutions that both have some disadvantages

The first solution mainly impacts the sprite editor. By inspecting the HTML I noticed an excess of sprite doc classes added to form the tables. This solution reduces the text output by switching some CSS classes to nested queries as follows:

• .spritedoc-names could become .spritedoc-box > ul. Saves 24 characters per unique sprite, roughly 50,000 characters for InvSprite.
• Replacing the <code> tags with CSS, since most of the styling is overridden anyways. Saves 11 characters per sprite name, roughly 26,000 characters for InvSprite.
• .spritedoc-name can become .spritedoc-box > ul > li. Saves 23 characters per sprite name, roughly 55,000 characters for InvSprite.
• Removing the <div> wrapper on the sprite images in favor of the CSS .spritedoc-box .sprite. Saves 35 characters per sprite, roughly 77,000 characters for InvSprite.
• Replacing .spritedoc-box with .spritedoc-boxes -> li. I'm pretty iffy on this one since it makes the CSS very ugly (.spritedoc-name becomes .spritedoc-boxes > li > ul > li), but it saves an additional 22 characters per unique sprite, roughly 50,000 total for InvSprite.

This all totals around 200,000 characters, which based on around 290 characters per sprite lets us add 650 more sprites before running into issues again (if including .spritedoc-box, we have around 250,000 extra characters with around 275 characters for each sprite, allowing around 900 more). I am not sure exactly how much this affects the sprite editor's performance as I only briefly looked at its code; it would mean switching a lot of class name references to HTML element references (many nested), which could have a performance impact, but it would only affect the sprite editor.

The second solution has an impact on sprite docs even if not using the sprite editor. This solution is to remove the image caching when on the sprite docs. This saves around 120 characters per sprite, totaling roughly 260,000 characters. This means each sprite is now around 270 characters (without the first solution), allowing us around 950 more sprite names before hitting issues. Of course, this has the side effect that the sprite doc may show different images than the actual page.

–KnightMiner ^t/_c 03:50, 17 June 2018 (UTC)

The Additions section in Java Edition 1.16 includes sprites on the right side so as not to break up the flow of text. Can we have the option to do this using a parameter?

The simplest way to do this might be to replace this:

root:node(sprite)
ifspriteTextthen
root:node(spriteText)
end

with this:

ifspriteTextandargs['right']then
root:node(spriteText)
end
root:node(sprite)
ifspriteTextandnotargs['right']then
root:node(spriteText)
end

and adding this to MediaWiki:Gadget-site-styles.css:

.sprite-text+.sprite{
padding-left:0.312em;
background-origin:content-box;
background-clip:content-box;
}

You can see this in action at Module:Sandbox/FnControlOption/Sprite (but with less elegant code since I don't have write access to MediaWiki:Gadget-site-styles.css)

— fn ⌃ ⌥ (talk · edits) 16:22, 25 September 2020 (UTC)

The sprites in this sprite module don't display anymore. Why is this the case? Is it to adapt for FandomDesktop? K1401986 Talk with me My edits 21:12, 9 June 2021 (UTC)

Currently, the nowrap class is used on the container to ensure the sprite is not visually disconnected from the text after it (when the text attribute is specified). The problem with this approach is that the text cannot be wrapped either, which tends to create scroll bars in infoboxes for some screen sizes (e.g., on my computer, the infobox on Spruce has a horizontal scroll bar). The fix for that was already suggested by KnightMiner back in 2015 (see #Nowrap): simply add white-space: normal; in the sprite-text class. I would do it myself, but I don't know where to find the stylesheets, and I likely do not have the permission to edit them. --MDLC01 13:05, 17 February 2023 (UTC)

Actually, I just found the stylesheets (just had to look 2 paragraphs above...): MediaWiki:Gadget-site-styles.css. What needs to be changed is adding white-space: normal; line 578. I indeed do not have the permission to edit the stylesheet. --MDLC01