Module talk:Inventory slot

From Minecraft Wiki
Jump to: navigation, search

Background / text font[edit]

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: , or . Regarding the background, I think it is included to Gamepedia but I'm not sure. — Itouchmasterpro d c 21:54, 2 February 2014 (UTC)

Some things about Grid[edit]

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. MattTalk
⎜ 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)

 Wait It would need its own module, but once such a module exists it might be possible to implement this. 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

Step 1
Banner Cocoa Beans +

Step 2
Banner Lapis Lazuli +
Banner +

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

Alternate brewing layout[edit]

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)

 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
}} 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
|Output 2=;Any Potion;Any Potion;Any Potion
}} 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. 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. 14:24, 28 April 2015 (UTC)

Add special aliases[edit]

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] )
return aliases
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] )
Maybe it could be split up further into repeatable patterns, like all banners which have normal/inverted versions.
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. 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. 22:39, 28 April 2015 (UTC)

Make the background optional[edit]

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. 21:08, 20 May 2015 (UTC)

You can already remove the background with class=plain:
What does removing the background have to do with customising the tooltip? MajrTalk
01:16, 21 May 2015 (UTC)
When you use the paramater args[title], it activates all the frames.
<span class="grid animated">{{grid|Dirt|title=One of the main blocks|class=plain}}{{Grid|Grass Block|class=plain}}</span>
Produces 15:27, 22 May 2015 (UTC)
{{grid|[A rock]Stone;[Grassy]Grass}} produces . 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 BlobsPaper JE2 BE2.png 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.

Incorrectly determines amount if the tooltip title contains a comma followed by a valid number[edit]


  • {{Slot|[Dirt,3 s]Sand,2[Melon,4 s]}}3
  • {{Slot|Diamond[Chance to obtain is 0,02% (decimal comma)]}}2

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)

Custom Images or Items[edit]

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

[[Pancake Stack|

with PancakeInvSprite.png 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 Nixinova sig1.png Nixinova sig2.png 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 Nixinova sig1.png Nixinova sig2.png 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)

Accessibility and disabled JS[edit]

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, Command BlockRepeating Command BlockChain Command Block, 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)

  1. unless they prefer Links, ELinks, or something else