Module talk:Inventory slot

Background / text font
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: http://hydra-media.cursecdn.com/hydra/fonts/minecraft.eot?#iefix, http://hydra-media.cursecdn.com/hydra/fonts/minecraft.woff or http://hydra-media.cursecdn.com/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)

Some things about Grid
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 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
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)
 * 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:


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

Alternate brewing layout
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)
 * There is another solution: You could display the sequence.

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.


 * 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)

Add special aliases
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)


 * – 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)

Smelting
I think there should be a parameter, 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, 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 and . These parameters would change whether the process/fuelusage is active.67.160.25.176 22:39, 28 April 2015 (UTC)

Make the background optional
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: Please state your opinion.67.160.25.176 21:08, 20 May 2015 (UTC)
 * Make the image its own function (perhaps p.icon). The function p.cell would be.
 * Add a paramater (maybe
 * We already have a paramater for the background, so there could be the option to hide the background by setting the paramater to.


 * You can already remove the background with :
 * 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, it activates all the frames.
 * Example


 * Produces
 * 71.212.10.80 15:27, 22 May 2015 (UTC)


 * [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)

“Matching”
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)