Module talk:Inventory slot

i tried to sue this module for my server wiki and i don't have a background / text police , why i can forget --Thesweetiger (talk) 21:34, 2 February 2014 (UTC)

You can download Minecraft font at these links: https://commons.gamepedia.com/media/hydra/fonts/minecraft.eot?#iefix , https://commons.gamepedia.com/media/hydra/fonts/minecraft.woff or https://commons.gamepedia.com/media/hydra/fonts/minecraft.ttf . Regarding the background, I think it is included to Gamepedia but I'm not sure. — Itouchmasterpro ^{d c} 21:54, 2 February 2014 (UTC)

First, this Module needs to change from anyone can edit to registered users can edit, since any vandalism would affect almost every article. Second, is there a way to add Armor and tool damage bars currently or in the future? --KnightMiner ^{(talk|contribs)} 15:39, 11 February 2014 (UTC)

In terms of actually implementing it, it wouldn't be difficult. The issue comes with what would the syntax be? I also wonder if it's something that is actually going to be used. If there's only like one instance where it is useful, I'd just upload a separate grid image with a damage bar included on it and just change the title and link. –Matt ᐸ Talk
Contribs ⎜ 04:43, 12 February 2014 (UTC)

Banners got multiples of different ways they can be displayed in the inventory depending on what patterns are applied to it. Is there any reasonable ways to support this without having to upload loads of grid images for possible pattern/color combos? :P Oozebull (talk) 18:37, 11 August 2014 (UTC)

👁 Image
 Wait It would need its own module, but once such a module exists it might be possible to implement this.71.212.10.80 13:33, 25 April 2015 (UTC)

This was already added in a different way using separate banner images, there is no need to create a separate module at this point. –KnightMiner ^t/_c 15:35, 25 April 2015 (UTC)

I mean custom banners. An example would be as follows:

Name	Ingredients	Crafting recipe	Description
Banner	Lapis Lazuli + Brown Banner	👁 Invicon Lapis Lazuli.png: Inventory sprite for Lapis Lazuli in Minecraft as shown in-game linking to Lapis Lazuli with description: Lapis Lazuli 👁 Invicon Lapis Lazuli.png: Inventory sprite for Lapis Lazuli in Minecraft as shown in-game linking to Lapis Lazuli with description: Lapis Lazuli 👁 Invicon Lapis Lazuli.png: Inventory sprite for Lapis Lazuli in Minecraft as shown in-game linking to Lapis Lazuli with description: Lapis Lazuli 👁 Invicon Lapis Lazuli.png: Inventory sprite for Lapis Lazuli in Minecraft as shown in-game linking to Lapis Lazuli with description: Lapis Lazuli 👁 Invicon Lapis Lazuli.png: Inventory sprite for Lapis Lazuli in Minecraft as shown in-game linking to Lapis Lazuli with description: Lapis Lazuli 👁 Invicon Lapis Lazuli.png: Inventory sprite for Lapis Lazuli in Minecraft as shown in-game linking to Lapis Lazuli with description: Lapis Lazuli 👁 Invicon Brown Banner.png: Inventory sprite for Brown Banner in Minecraft as shown in-game linking to Brown Banner with description: Brown Banner 👁 Invicon Banner.png: Inventory sprite for Banner in Minecraft as shown in-game linking to Banner with description: Banner	Step 1
Banner	Cocoa Beans + Banner	👁 Invicon Cocoa Beans.png: Inventory sprite for Cocoa Beans in Minecraft as shown in-game linking to Cocoa Beans with description: Cocoa Beans 👁 Invicon Banner.png: Inventory sprite for Banner in Minecraft as shown in-game linking to Banner with description: Banner 👁 Invicon Cocoa Beans.png: Inventory sprite for Cocoa Beans in Minecraft as shown in-game linking to Cocoa Beans with description: Cocoa Beans 👁 Invicon Cocoa Beans.png: Inventory sprite for Cocoa Beans in Minecraft as shown in-game linking to Cocoa Beans with description: Cocoa Beans 👁 Invicon Banner.png: Inventory sprite for Banner in Minecraft as shown in-game linking to Banner with description: Banner	Step 2
Banner	Lapis Lazuli + Banner + Vines	👁 Invicon Lapis Lazuli.png: Inventory sprite for Lapis Lazuli in Minecraft as shown in-game linking to Lapis Lazuli with description: Lapis Lazuli 👁 Invicon Banner.png: Inventory sprite for Banner in Minecraft as shown in-game linking to Banner with description: Banner 👁 Invicon Vines.png: Inventory sprite for Vines in Minecraft as shown in-game linking to Vines with description: Vines 👁 Invicon Banner.png: Inventory sprite for Banner in Minecraft as shown in-game linking to Banner with description: Banner	Step 3.

As you can see, there isn't going to be such a file.71.212.10.80 13:53, 26 April 2015 (UTC)

Would it be a good idea to modify the brewing layout from the vanilla layout slightly to allow an input and output slot? Issues would include possible confusion from readers as to its look in game, but it would solve the confusion caused by a lack of an input image. –KnightMiner ^(t·c) 04:46, 6 January 2015 (UTC)

👁 Image
 Oppose There is another solution: You could display the sequence.

{{Brewing Stand
|Input=;;Magma Cream;
|Output 2=;Akward Potion;Akward Potion;Potion of Fire Resistance
}}

71.212.10.80 02:21, 25 April 2015 (UTC)

I would have to disagree to using animation to show the recipes, for two reasons. Firstly, everywhere else animation states alternatives, specifically on the other recipes, so using something different in this one case would mainly be inconsistant. Secondly, the main usage of the layout is on articles such as Redstone, where there are so many potions that it would take way too long to cycle through every type. –KnightMiner ^t/_c 03:04, 25 April 2015 (UTC)

For that, there is another solution.

{{Brewing Stand
|Input=;;;;;;;;;;Redstone;;Redstone;Redstone;Redstone;Redstone;Redstone;Redstone;Redstone;Redstone;Redstone;Redstone;;;;;;;;;;;
|Output 2=;Any Potion;Any Potion;Any Potion
}}

71.212.10.80 13:43, 25 April 2015 (UTC)

The thing is, redstone does not use simply use "any potion", it only uses only specific potions. Also, that "solution" still has over 30 frames, which would last over a minute simple to see the full recipe, which is the exact problem I was stating above. –KnightMiner ^t/_c 15:57, 25 April 2015 (UTC)

I agree with an alternate brewing layout then. I notice you haven't answered the message I left you on the sandbox talk page.71.212.10.80 14:22, 26 April 2015 (UTC)

I did not see that messsage, as that is a somewhat obscure place to leave the message. Since it related to more than just my code (to this module instead), this page would have been a better place to leave the message.

As for the specific idea, that layout could work, although it still faces the same problem as either one of my proposals, as it does not appear that way in game, thus could lead to some confusion. –KnightMiner ^t/_c 21:05, 26 April 2015 (UTC)

The idea is that it includes the inventory below, so it looks more like the real GUI.71.212.10.80 14:24, 28 April 2015 (UTC)

Certain aliases, such as the music discs or the damaged tools simply repeat a pattern over and over again, causing redundancies in the alias module. That also prevents adding aliases for proper display of the banner pattern titles, as hundreds of them would be a pain to add and update.

A simple solution would be adding "special aliases", which would basically be aliases with a bit of logic rather than simple text return.

To enable this using the module [[Module:Grid/SpecialAliases]], I need the code

-- Comment this next line out if you're not using special aliases
local specialAliases = require( 'Module:Grid/SpecialAliases' )

added after the original alias declaration on line 24, the code

if aliases or modAliases then

from line 33 changed to

if aliases or specialAliases or modAliases then

and the code

elseif specialAliases and specialAliases( id ) then
 alias = specialAliases( id )

added after line 47.

Because of the way it is coded, aliases take precedent over special aliases, causing alias to also act as a sort of "blacklist" for names that should not match the special aliases.

–KnightMiner ^(t·c) 19:31, 4 February 2015 (UTC)

/tp Majr ~ ~ ~ –KnightMiner ^(t·c) 17:29, 10 February 2015 (UTC)

I'm not a fan of having this code run (twice) on every invoke. Entries in the table are cheap, so don't worry about how many there are. If less repetitive code is what you're after, you could add a pre-processing stage to the alias table to add these "special" aliases before the table is output. Something like:

local aliases = [the normal table definition]
for _ in ipairs{ [list of banners] } do
 table.insert( aliases, [banner stuff] )
end
[etc.]
return aliases

–Majr ᐸ Talk
Contribs 09:37, 11 February 2015 (UTC)

The main thing I'm after is not having to add 608 aliases to the alias table, when each one would be the same as the last except changing one word.

We could attempt to insert all the banners into the alias table. I assume you mean something like these: ([[Module:KnightMiner/Aliases]] and [[Module:KnightMiner/Banners]]) That would remove the redundant code and prevent the banners from being processed once per #invoke:, with the minor downside of new banners needing to be added manually. (although, I doubt many new patterns will get added any time soon)

–KnightMiner ^(t·c) 17:29, 11 February 2015 (UTC)

Well you wouldn't need to have every variation of banner, just the unique repetitions:

for _, colour in ipairs{ [colours] } do
 for _, banner in ipairs{ [banner types] } do
 table.insert( aliases, [colour .. banner] )
 end
end

Maybe it could be split up further into repeatable patterns, like all banners which have normal/inverted versions.

–Majr ᐸ Talk
Contribs 07:12, 12 February 2015 (UTC)

That would have made a lot more sense than what I did...

As for splitting it up further, I could not find enough similarities between the various patterns to justify that, as for example, inverted is only used four times, and indented is used in the other places.

Anyways, that is now implemented, so there are a few extra modules that can be deleted.

–KnightMiner ^(t·c) 15:23, 12 February 2015 (UTC)

I think there should be a parameter {{{Inactive}}}, used for wether the process icon should be in its inactive state. This would allow you to show whether the process is at the beginning or the end. For the burning, you can use |fuelusage=fire (in-active), but this wouldn't work for the process because the image name puts inactive after the word process. There needs to be a way to put an inactive process.71.212.10.80 14:31, 28 April 2015 (UTC)

What article specifically needs to show the process at its end? As for an actual "inactive" parameter, that is already controlled through the fuel and input, notice when you call the furnace normally, it is not burning:

But when you call it with an input and fuel, it is burning:

If you need the process to be inactive, simply omit the fuel like so:

–KnightMiner ^t/_c 14:48, 28 April 2015 (UTC)

I was thinking of an add-on for sponge.

As you can see, the fuelusage is inaccurate in the third frame and the process is inaccurate in the fourth frame. In this case, the error is different, though. Maybe there could be parameters like {{{changefuelstate}}} and {{{changeprocessState}}}. These parameters would change whether the process/fuelusage is active.67.160.25.176 22:39, 28 April 2015 (UTC)

I think the background should be optional, meaning that the class "grid" would be removed. This would be useful if you want to customize the tooltip for some but not all of the images in an animation or want to change the different frames in different ways or if you just don't need the background. Note that using {{SimpleGrid}} does not count because it has a lot less features (some of the missing features include animation and aliases). There are 3 ways to achieve this:

• Make the image its own function (perhaps p.icon). The function p.cell would be return '<span class="grid">..'p.icon'...
• Add a paramater (maybe args[hidebackground]
• We already have a paramater for the background, so there could be the option to hide the background by setting the paramater to none.

Please state your opinion.67.160.25.176 21:08, 20 May 2015 (UTC)

You can already remove the background with class=plain: 👁 Invicon Grass Block.png: Inventory sprite for Grass Block in Minecraft as shown in-game linking to Grass Block with description: Grass Block
👁 Invicon Dirt.png: Inventory sprite for Dirt in Minecraft as shown in-game linking to Dirt with description: Dirt

What does removing the background have to do with customising the tooltip? –Majr ᐸ Talk
Contribs 01:16, 21 May 2015 (UTC)

When you use the paramater args[title], it activates all the frames.

Example

<span class="grid animated">{{Inventory slot|Dirt|title=One of the main blocks|class=plain}}{{Inventory slot|Grass Block|class=plain}}</span>

Produces

👁 Invicon Dirt.png: Inventory sprite for Dirt in Minecraft as shown in-game linking to Dirt with description: One of the main blocks
👁 Invicon Grass Block.png: Inventory sprite for Grass Block in Minecraft as shown in-game linking to Grass Block with description: Grass Block
71.212.10.80 15:27, 22 May 2015 (UTC)

{{Inventory slot|[A rock]Stone;[Grassy]Grass}} produces 👁 Invicon Stone.png: Inventory sprite for Stone in Minecraft as shown in-game linking to Stone with description: A rock
👁 Invicon Grass.png: Inventory sprite for Grass in Minecraft as shown in-game linking to Grass with description: Grassy
. There is no need to overdevelop a feature just so you can have ashortcut to assign three of the four names the same title, especially when we rarely use titles outside of aliases. –KnightMiner ^t/_c 01:54, 23 May 2015 (UTC)

Where the prefix “Matching” is used? — Agent NickTheRed37 (talk) 16:26, 30 March 2016 (UTC)

"Matching" is used in Module:Inventory slot/Aliases for WIP idea described here, which labels ingredients of a recipe as needing to be the same, rather than "Any" which means any type may be used freely. Aliases currently only exist for wood stuff, but the goal is to implement this for all recipe types eventually, then maybe randomly offset recipes with the "Any" prefix (to drive across the idea that any type can be used), while keeping "Matching" matching. For now "Matching" is the same as "Any" though other than displaying a different word on the ingredients column. –KnightMiner ^t/_c 21:20, 1 April 2016 (UTC)

Okay, thanks. I’m translating the module system to Russian; the language has a crazy level of declension, so I have to rewrite most of the Aliases module that automatically generates item names so they fit into Russian language’s rules. — NickTheRed37 (talk) 15:50, 13 April 2016 (UTC)

There should be a function for customizing anvils. This way, an anvil screen can be displayed without uploading a file, and readers can hover over the item to see what it is. What do other users think? The Blobs^{👁 Image}
02:43, 22 April 2016 (UTC)

Are there that many cases that use an anvil? I know some Modded MC recipes use anvils, but in vanilla all recipes are either item + itself or item + book. I guess at most it could be used to show repair materials, but that is just an A=B list, which a simple table might do better. –KnightMiner ^t/_c 04:15, 22 April 2016 (UTC)

There is a missing recipe for cloning maps in pocket edition. It is true that a file could be uploaded, but readers should be able to hover over items and see what they are.

Testcases:

• {{Slot|[Dirt,3 s]Sand,2[Melon,4 s]}} → 👁 Invicon Sand.png: Inventory sprite for Sand in Minecraft as shown in-game linking to Sand with description: Dirt,3 s Melon,4 s
  2
• {{Slot|Diamond[Chance to obtain is 0,02% (decimal comma)]}} → 👁 Invicon Diamond.png: Inventory sprite for Diamond in Minecraft as shown in-game linking to Diamond with description: Diamond Chance to obtain is 0,02% (decimal comma)
  

Actual displayed amount should be 2 in the first case and 1 (not displayed) in the second case. Currently, 3 is displayed in the first case and 2 is displayed in the second case.

	frame.num = math.floor( frameText:match( ',(%d+)' ) or 0 )

match looks for the first match, and a matching character sequence may be present in the tooltip title (or in the tooltip text, so we can't just iterate and pick the last match). Doesn't look to me like a really simple fix exists. --AttemptToCallNil (report bug, view backtrace) 10:35, 18 February 2018 (UTC)

Updated test cases. On a side note, the module crashed because I tried to insert a colon into the toolip text for the second test case. --AttemptToCallNil (report bug, view backtrace) 10:47, 18 February 2018 (UTC)

Are the tooltip title/text supposed to be able to determine the displayed number/stack size? If not, then the simplest fix would be to just remove them from the string (or at least create a second string with them stripped) before trying to match on the number, I think. (Really, what the module should be doing is fully separating the input string into up to three components; for the item and quantity, the tooltip title, and the tooltip text; and then proceeding with each individually as needed.) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 14:47, 18 February 2018 (UTC)

Is there any way to add a custom image/item to a crafting recipe? For example.

{{Crafting Table
|A1= Sweet Berries |B1= Milk Bucket |C1= Sweet Berries
|A2= Egg |B2= Sugar |C2= Egg
|A3= Wheat |B3= Wheat |C3= Wheat
|Output= [[File:PancakeInvSprite.png]] (Pancake Stack)
}}

would output

with 👁 Image
in the output slot with the mouseover tag of "Pancake Stack".

I've tried to put only the image in, but it glitches out and states there's a problem with the module.

DarthKeidran (talk) 23:51, 15 April 2019 (UTC)

From my knowledge I think the file has to be called something like "File:Grid Pancake Stack.png", so try moving it there and using output=Pancake Stack. – Nixinova 👁 Image
 👁 Image
23:56, 15 April 2019 (UTC)

I've made [[:File:Grid Pancake Stack.png]] into a redirect to your file, and now that crafting recipe works. – Nixinova 👁 Image
 👁 Image
00:00, 16 April 2019 (UTC)

Thank you. I couldn't seem to figure it out, and that makes so much sense now.

DarthKeidran (talk) 05:11, 17 April 2019 (UTC)

Currently (as I pointed out on a discussion on Talk:Block), this template/module is not accessible to users using screen readers. While I'm pretty sure this is not the only accessibility problem with the wiki (e.g. abuse of definition lists, which seems to be a thing on most wikis), it's probably one that's easy to solve since it just requires fixing this module. And this isn't actually an issue exclusive to screen readers -- it also affects everyone's favorite^{[nb 1]} terminal browser Lynx (only a few blocks actually show up - those with animations that are stored in separate files it seems).

Unfortunately, I'm not quite sure how to fix this. It seems like the key part of the issue is a lack of alt text on slots, but alt text is only available for regular images. That's presumably why it worked for fire and such, but nothing else. The spritesheets use a span tag, and that can't have alt text as best as I can tell; instead it's supposed to have text in the body. But that text is rendered over the image, which we don't want... I'm not sure how to go about fixing it. (It's worth noting that there is already a title element which does show up if JS is disabled (it's replaced by the minetip if JS is enabled, but the current behavior is progressive enhancement, so that's good), but screen readers don't use that.)

The other thing is the animation, which just doesn't provide useful results if JS is disabled; only the first item shows up. That's probably mostly OK for some things, but e.g. the block list requires seeing all of the blocks for things to be useful, and the same goes for recipes. For recipes, a valid (perhaps more useful) replacement would be the text "Any Planks" or such, though blocks don't need that. A relevant example is the info for command blocks, 👁 Invicon Command Block.png: Inventory sprite for Command Block in Minecraft as shown in-game linking to Command Block with description:
👁 Invicon Repeating Command Block.png: Inventory sprite for Repeating Command Block in Minecraft as shown in-game linking to Command Block with description:
👁 Invicon Chain Command Block.png: Inventory sprite for Chain Command Block in Minecraft as shown in-game linking to Command Block with description:
, which only shows up as "command block" if JS is disabled (though interestingly, lynx shows all 3, probably since it doesn't understand CSS either). The ideal way for these animated ones to be read in general is just to list all of them, possibly (particularly for recipes, but not for the blocks page) as "Slot containing Command Block[link] or Repeating Command Block[link] or Chain Command Block[link]".

With MC itself focusing on improving accessibility in the past few updates, we probably should to. I know that what I've written here is a bit of a mess, but hopefully it at least is a starting point. --Pokechu22 (talk) 18:48, 27 April 2019 (UTC)

There are quite a few areas where Inventory slot could see improvement.

First of all, when looping over aliasFrames, p.getAlias does some unnecessary duplication of alias data that is ultimately fetched from Module:Inventory slot/Aliases using mw.loadData, which is only meant to load it into Lua memory once. The cloning is done so that the expanded frames' title, text, mod and stack size parameters could be overridden with those of parentFrame; i. e. [Log]Any Log ({name = "Any Log", title = "Log"}) would give all the logs with "Log" instead of whatever titles the individual logs use. However, such use cases are definitely not common; most of the time aliases are used without additional parameters, so the function should just use the aliasFrame directly if none of parentFrame's extra fields are set.

More explanations are coming later because I don't have enough time to write them all right now; I'll leave a link at this page where I describe how the module works and some issues.

— BabylonAS 04:57, 25 September 2023 (UTC)

Moving on to issues that are less likely to happen, the p.parseFrameText and p.makeFrame functions have many problems with special character processing. Some of them were mentioned above, but that's only a tip of the iceberg as things get funky when using colons or semicolons inside titles or subtext. Colons would confuse makeFrame as it doesn't check if the colon is inside square brackets, which means it could pull the mod's name out of the item's tooltip title, with the item's name starting after that colon and thus including part of the tooltip title as well. Moreover, spaces around commas and colons are trimmed away (it doesn't happen to aliases with colons because they are already in table form, meaning that makeFrame is not used in the first place). As for semicolons, p.parseFrameText likewise doesn't check for square brackets. I'm addressing some of these issues in my fork of Inventory slot (sandbox), which borrows some code written by AttemptToCallNil to deal with semicolons (used in the Russian version of Inventory slot that desperately needs a rebase).

Also in parseFrameText, there is a bug where this line attempts to compare the number of subframes with i which is not defined anywhere. That specific clause appears to only fire when the whole frame text consists of a subframe container and nothing else; i. e. surrounded by braces. In that case, i should mean the current frame index, and thus defined in line 285 in the for loop's header.

Back to makeFrame, it would be nice to have frame.num nillified if it equals 1, as a stack size of 1 would not be shown anyway. This would synergize with the getAlias optimization requested above.

In makeItem (line 92), the patterns for matching file extensions are incorrect as Lua patterns use percent signs instead of backslashes to escape special characters, in this case dots.

Given that the English Minecraft Wiki is done with mods, I guess we could just strip mod support completely? This will also simplify rewriting makeFrame. But we need to make sure there are no remaining mod uses for Inventory slot.

Finally, we could start using TemplateStyles instead of MediaWiki:Gadget-site-styles.css to set the slot's styles.

— BabylonAS 08:46, 25 September 2023 (UTC)

Underlined some issues that were addressed by now, alongside sprite support being dropped. Also, looks like TemplateStyles is not as practical for Slot as I thought it to be, while testing the proposed getAlias optimization on the dev wiki led to some conflicting results as Lua memory usage actually rose in many cases. — BabylonAS 05:50, 4 October 2023 (UTC)

In particular, does this module except [square brackets] at all? --Simanelix ^(T|C) 19:31, 17 April 2024 (UTC)

What exactly do you mean? Square brackets are used to re-define the tooltip: before the item's name, they set the title; after it, they set the additional text (like lore or damage info). BabylonAS 19:41, 17 April 2024 (UTC)

Currently the module supports overriding title and lore for an icon in the frame string using square brackets, such as [&b&oSteamed Bun Invasion]v:Netherite Sword[&7Sharpness V/Looting III/Unbreaking III/Mending//When in Main Hand:/&2 11 Attack Damage/ 1.6 Attack Speed] for 👁 Invicon Netherite Sword.png: Inventory sprite for Netherite Sword in Minecraft as shown in-game linking to Netherite Sword with description: Steamed Bun Invasion Sharpness V Looting III Unbreaking III Mending When in Main Hand: 11 Attack Damage 1.6 Attack Speed
. The parser works with quite some issues as I’ve had to prepend v: (vanilla override) due to the presence of a colon in the lore, while whitespace before the attack numbers is gone due to overly aggressive trimming. RuMCW uses a more robust parser which is however more computationally expensive.

It’s been argued that the ability to use complex formatting in-line (instead of using aliases) is not really needed. I’m willing to debate that: title override could be useful in, for instance, version articles (example) to display names correct for those versions (do we really need to add aliases for every single historical name?). But I do agree that such cases are rare.

A possible solution is to implement a separate JSON mode which would have full support for frame settings (and translate seamlessly into the module’s internal table format) while removing support for square bracket syntax from the standard (or “easy mode”) string parser. However, how would the module understand it’s being fed JSON? Adding a separate parameter would require adding support for it in Module:UI, Module:Infobox etc. A possible alternative is implementing a special marker (like %JSON%:) that would precede the actual JSON string, but that’s a bit kludgy. BabylonAS 10:56, 17 January 2025 (UTC)

Given that the usual frame string syntax differs greatly from JSON, we might actually not need any special markers. A JSON list is wrapped in square brackets, and a single JSON object is in curly braces. We could just check if the frame string is wrapped in either of these, then check if is valid JSON. BabylonAS 13:44, 8 March 2025 (UTC)

The alt text should simply be the item's name/description – e.g. the alt text of a Potion of Oozing slot:

👁 Invicon Potion of Oozing.png: Inventory sprite for Potion of Oozing in Minecraft as shown in-game linking to Potion of Oozing with description: Potion of Oozing Oozing (03:00)

should simply be "Potion of Oozing (3:00)", or something like that. Currently, though, the alt text of that slot is "Invicon Potion of Oozing.png: Inventory sprite for Potion of Oozing in Minecraft as shown in-game linking to Potion of Oozing with description: Potion of Oozing Oozing (03:00)" – which is way, way, too long! Alt text needs to be short and sweet so that screen readers don't spend too much time reading them out (see wikipedia:MOS:ALT). {{Lemondoge|Talk|Contributions}} 16:35, 3 December 2025 (UTC)

Retrieved from "https://minecraft.wiki/w/Module_talk:Inventory_slot?oldid=3419050"