Minecraft Wiki
Advertisement

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? {{#var:articleisplanned}} 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... MajrTalk
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. MajrTalk
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|c) 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|c) 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? MajrTalk
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 ignoreusage them all, but new tools would need to be added manually. --KnightMiner (t|c) 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. MajrTalk
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|c) 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. MajrTalk
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 type 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|c) 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|c) 02:06, 21 September 2014 (UTC)

 Done. MajrTalk
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.MajrTalk
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 belowSealbudsman 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 Any same Wood Planks, leading to the new test '^Any same '? 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 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 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. MajrTalk
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 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 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. MajrTalk
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 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. MajrTalk
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 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. MajrTalk
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 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. MajrTalk
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. MajrTalk
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 talk/contr 13:12, 9 October 2015 (UTC)
Crafting grid for door and fence seem to have a problem in their output slots. – Sealbudsman talk/contr 20:56, 9 October 2015 (UTC)
 Fixed. 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. MajrTalk
Contribs
10:19, 5 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 talk/contr 05:35, 9 October 2015 (UTC)

 Done. 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. MajrTalk
Contribs
07:21, 9 October 2015 (UTC)
It looks good, I see how it works on shears. Thanks! – Sealbudsman talk/contr 13:18, 9 October 2015 (UTC)
Advertisement