Module talk:Crafting

Upcoming parameter
Would it be possible for this template to not categorize articles as Category:Upcoming if they're already in Category:Planned, like Upcoming does? can be used for this. —F‌enhl 15:12, 5 August 2014 (UTC)


 * If they are upcoming, then they should be in the upcoming category... –Majr ᐸ Talk Contribs ⎜ 03:47, 7 August 2014 (UTC)


 * Actually, that's not how the category is being used. Articles about upcoming features (as marked by Snapshot) go in Category:Planned, other articles with references to upcoming features fo in Category:Upcoming. (It does however help that Planned is a subcategory of Upcoming.) —F‌enhl 03:50, 7 August 2014 (UTC)


 * Hmm, it seems that planned is being used as a duplicate of upcoming, and future is being used for what planned is meant for. –Majr ᐸ Talk Contribs ⎜ 04:12, 7 August 2014 (UTC)

Red Sandstone Category
elseif v:find( ' Red Sandstone$' ) then v = 'Red Sandstone' needs to be added before elseif v:find( ' Sandstone$' ) then v = 'Sandstone' Or red sandstone recipes get tagged as sandstone. --KnightMiner  (t 18:29, 6 August 2014 (UTC)

Category for repair recipes
Can code along the lines of: elseif v:find( '$Damaged ' ) then v = 'Damaged' be added? (is that how you search the beginning of the string?)

Basically it would allow all the tool/weapon repair recipes to be pulled up automatically using crafting usage on Item repair and other such pages. --KnightMiner  (t 15:55, 17 September 2014 (UTC)


 * But any two of the same damaged item can be crafted together to get a repaired one, it's not just particular ones. What value is there in having 50 crafting recipes showing almost the same thing, which could just as well be stated with a single sentence? –Majr ᐸ Talk Contribs ⎜ 05:42, 18 September 2014 (UTC)


 * The main value would have been the automatic, and with our page format, that would contain only 10 recipes right now. Otherwise I could simply merge and  them all, but new tools would need to be added manually. --KnightMiner  (t 14:10, 18 September 2014 (UTC)


 * I'm not talking about making it automatic, I'm talking about having it on the page at all. All damaged items can be repaired by putting two of the same next to each other in the crafting window. That sentence is enough to explain it just as well as the 50 recipes (including animations), so I don't see the need to have them at all. –Majr ᐸ Talk Contribs ⎜ 01:18, 19 September 2014 (UTC)


 * The main reason was it was not getting stated at all, except on an article that was rarely linked to, or in rare cases it got stated as trivia. Also, there really was no place to put the sentence on the page that still looked fine, as stating next to the crafting table that you can also use this unshown recipe to repair the tool was a little odd. --KnightMiner  (t 03:23, 19 September 2014 (UTC)


 * I'm talking about the usage on item repair. The usage on the item pages themselves would be the same regardless. –Majr ᐸ Talk Contribs ⎜ 03:54, 19 September 2014 (UTC)


 * Yeah, that page would likely look fine without it, although I would have to find a good place for the  parameter if we still want them to load the repair recipes using Module:Recipe list. I will likely just add it on the pages themselves, although it would be a bit too much repetition with seven different tool pages to load. (plus two combat and one transportation) --KnightMiner  (t 04:07, 19 September 2014 (UTC)

Description column
Can the code if ( args.description or  ) ~=  and f:callParserFunction( '#dplvar', 'craftingdescription' ) == '1' then table.insert( row, args.description ) end Be changed to	local descriptionCell = args.description or '' if f:callParserFunction( '#dplvar', 'craftingdescription' ) == '1' then table.insert( row, descriptionCell ) end Basically if the description column is set, it will display an empty cell rather than an missing cell. Empty cells do visually look better than a missing cell, and it would look slightly more professional.

--KnightMiner  (t 02:06, 21 September 2014 (UTC)


 * . –Majr ᐸ Talk Contribs ⎜ 04:57, 21 September 2014 (UTC)

Shapeless recipes marked as shaped recipes
Why are some shapeless recipes marked as shaped recipe ? I'm talking about the code following "Automatic shapeless positioning".

The consequence is recipes like this one http://minecraft.gamepedia.com/Coal#Crafting don't have the indication that the recipe is shapeless (= you can place the block of coal where you want in the grid). --Rom1504 (talk) 02:15, 1 May 2015 (UTC)


 * That isn't what shapeless is. Almost all recipes that aren't too large can be placed anywhere in the grid and even flipped horizontally. Shapeless means the ingredients can be placed in any order, if there's only one ingredient, there's only one way it can be placed, and therefore isn't shapeless. –Majr ᐸ Talk Contribs 02:41, 1 May 2015 (UTC)


 * Okay I understand better the logic behind that, thanks for the explanation ! --Rom1504 (talk) 16:46, 1 May 2015 (UTC)

Want to add 'Any of the same Wood Planks'
As I've set up an alias for this in this edit (which has since been improved). The use case is to differentiate between where the wood has to be all the same, and where it can be different. The issue with this now is that it links to of the same Wood Planks. I would have to put an branch in here that tested for '^Any of the same ', in front of the branch on line 79 that already tests for '^Any '. Is this okay? – Sealbudsman talk/contr 19:33, 8 October 2015 (UTC)

EDIT: instead, want to add 'Matching Wood Planks', needing a branch for '^Matching ', per discussion below – Sealbudsman talk/contr 04:43, 9 October 2015 (UTC)


 * It should function fine, and I see this as something worth noting. The name might be a bit long, maybe use something like, leading to the new test  ? – KnightMiner  t/c 19:50, 8 October 2015 (UTC)


 * Aha. What about 'Matching Wood Planks', as that makes grammatical sense, plus does away with the notion of 'any'? (The reason I'm coming here of course is that someone with permissions can take this up – didn't know if that was clear.) – Sealbudsman talk/contr 20:01, 8 October 2015 (UTC)


 * "Matching Wood Planks" sounds like the best name so far. (I figured you were asking for someone with permissions, I just always like to leave a vote of support if I agree with an idea that requires such attention). – KnightMiner  t/c 03:57, 9 October 2015 (UTC)


 * Ah thanks! If this edit gets done, would you mind setting up the alias for it? – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 04:43, 9 October 2015 (UTC)
 * Also 'Matching Wool' could be used for Carpet and Banner, 'Matching Dye' could be used for Banner emblazons; 'Matching Stained Glass' could be used for Stained Glass Panes – although you could argue it's less ambiguous, less needed in these cases.. – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 05:46, 9 October 2015 (UTC)


 * To take this further, if we start using matching x for the matching cases and any x for when it doesn't matter, we could have the starting frame for any x be randomised to make it more obvious that it doesn't matter. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 06:01, 9 October 2015 (UTC)


 * How hard/efficient would it be to have the "Any" aliases use a new "random animation" which just makes the frames completely random? JavaScript has a random number function, so we could effectively count the number of frames (or maybe pass it on as data to make things easier) then choose a random from 1 to that number and set that frame number to display. – KnightMiner  t/c 00:38, 10 October 2015 (UTC)


 * Whether 'Any' gives you completely random frames per-slot, or random starting offsets per-slot, you'd have to account for cases like Firework Star, where you want your output color to always match your input color, and both take 'Any'. Maybe if input and output both have 'Any', you just make sure their index is aligned?  – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 02:56, 11 October 2015 (UTC) EDIT: I take it back.  Any case with 'Any' on both sides is either a candidate for 'Matching' on the input side, or it's just a single 'Any' on the input side, and single 'Any' doesn't need to be randomized.  Right?  – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 04:46, 11 October 2015 (UTC)


 * The point of using matching is to say that these ingredients and output have to go together, so that any means it doesn't matter. We might want to modify the name column to trim off the matching prefix, because "Matching Firework Star" sounds a bit strange for the name. As for randomising all frames, that would be possible to modify the script to do that, but I think it would be good enough to have different starting points, which can easily be done without modifying the script at all. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 05:51, 11 October 2015 (UTC)


 * How about this. 'Any' on the input side gets randomization, unless there is an 'Any' on the output side, then the template displays the input 'Any' as 'Matching'.  And we do away with the 'Matching' alias prefix altogether: template syntax would always use 'Any'. – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 14:49, 11 October 2015 (UTC)


 * That wouldn't work with firework stars, where only the dye is matching, and the extra ingredients are any. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 04:32, 15 October 2015 (UTC)


 * Oh you're right. The charge + dye -> charge recipe suffers from that.  Although now I don't think our original idea would handle that any better. – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 13:00, 15 October 2015 (UTC)


 * Why not? The input and output star would be matching, and the dye would be any. The tooltip description already doesn't show the shapes and fades, so it'd be no worse off.
 * I don't think there's anyway the module can know that any particular set of items are matching. It really needs to be done manually. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 10:14, 21 October 2015 (UTC)


 * I was only thinking that 'Matching Star' on the input sounded odd since there is no other input star to match against. Although there's nothing stopping us from displaying Matching as Any, in these cases where there's a single item -- using the Matching signifier only to force the animation to start at 0.
 * Alright, I'm done poking holes, I'm satisfied now this would all work. Thanks for humoring me! – Sealbudsman <span style="transform: rotate(-18deg); display: inline-block; top: -1px; position: relative;">talk/contr 14:45, 21 October 2015 (UTC)


 * I think of it as matching the output star, since you're getting that back with the extra shape/fade added on. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 09:46, 22 October 2015 (UTC)


 * I've added the matching prefix, and it is now being used on boat. If we like this (and the above), then we probably want to just have a matching x for each any x, rather than finding which ones are used in a matching state. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 07:17, 9 October 2015 (UTC)


 * Great!
 * I do like the randomized starting frame. Another thing, maybe unnecessary depending how it looks: could all the frames be randomized?
 * Seems to work well on boats. I agree it would be nice to generically make sure all 'Any' have a 'Matching' to go with it.  The suggestions above, Carpet, Banner, emblazons and Stained Panes were simply the only other examples I could identify. – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 13:12, 9 October 2015 (UTC)


 * Crafting grid for door and fence seem to have a problem in their output slots. – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 20:56, 9 October 2015 (UTC)


 * . It was creating the alias name based on the name from the table "woodNames", rather than just using that name for the items in the alias. – KnightMiner  t/c 00:27, 10 October 2015 (UTC)

We now have "Matching *" for (almost) every "Any *" alias. Once all pages which require matching items are changed to the new aliases, we can change the any aliases to have a random starting frame. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 10:19, 5 September 2016 (UTC)


 * There's an issue (I don't know if it's new or not) where Wood Planks shows Oak Wood Planks for Sword, because of the way it's being used on Sword EDIT: same with all wooden tools. Easier to just split up the crafting section on those pages? – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 01:43, 6 September 2016 (UTC)


 * That's always been an issue. Separating the recipe is the easiest way to fix it, but isn't the most ideal presentation. I have considered adding "Random *" as a special prefix, which is a single frame, but picks a random "sub-frame"(?) each time the frame is displayed, in order to represent "Any *" in a single frame. It would also act as a normal "Any *" when it's the only frame. The difficulty is implementing it. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 03:35, 7 September 2016 (UTC)


 * I see. A separate issue, to be solved some other time I guess.
 * Checking through Crafting, pretty sure I've got every case of 'matching' changed over, at this point. – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 11:53, 7 September 2016 (UTC)


 * , are we to be putting 'Matching' in both the output and the input? If that's the case we should probably not have it say 'Matching' in the output, and also this would have to be done on Fence, Fence Gate, Door, Boat, Stair, Slab, Carpet, and Glass Pane as well as Banner.  Am I understanding your recent edit correctly? –  Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 18:36, 11 September 2016 (UTC)


 * –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 02:59, 12 September 2016 (UTC)


 * What was done? – Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 04:23, 12 September 2016 (UTC)


 * Removed "Matching" from the name column. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 05:30, 12 September 2016 (UTC)


 * Right. I must have been zonked.  So those other pages are changed over, too. –  Sealbudsman <span style="transform: rotate(-16deg); display: inline-block; top: -1px; position: relative;">talk/contr 11:49, 12 September 2016 (UTC)

add a case for '^Damaged ' tools
In a similar vein to the suggestion directly above, if we checked for '^Damaged ' then we wouldn't have to have all kinds of redirects like Damaged Elytra and Damaged Diamond Hoe. – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 05:35, 9 October 2015 (UTC)


 * . Damaged is now a prefix. As a bonus, Invslot removes "Damaged" from the image link, so the redirects are probably entirely unnecessary now, and it will no longer create an unnecessary self link. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 07:21, 9 October 2015 (UTC)


 * It looks good, I see how it works on shears. Thanks! – Sealbudsman <span style="transform: rotate(-12deg); display: inline-block; top: -2px; position: relative;">talk/contr 13:18, 9 October 2015 (UTC)