Module talk:Sprite

Nowrap
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  . –Majr ᐸ Talk Contribs 13:47, 24 March 2015 (UTC)

Merge types
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 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 Grid Empty Map.png 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 Grid Empty Map.png 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, 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 (, which, when run, would give ), 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)