Template talk:Recipe/Archive 2

Recipe craft categories

I've been seeing a lot of manually added categories like "Chef recipes", "Leatherworker recipes". I like these categories, I just think they'd be better added through this template. ~ Sanna 13:18, 22 January 2013 (UTC)

Create sub templates for 'double' parameters

If we create sub templates that handle the input of the mat, amt and discipline fields, we can reduce the amount of (duplicate) code needed within the main code and also make it easier to maintain the template itself. ~ Sanna 13:20, 22 January 2013 (UTC)

No need, we will soon be getting an extension that provides the #arraymap parser function, which will allow us to properly handle multi-valued parameters. —Dr Ishmael 13:30, 22 January 2013 (UTC)

Where to use?

I feel this page needs a description of where exactly it should be used. -Chieftain Alex 21:02, 26 February 2013 (UTC)

Different types of recipes

Can the template be adjusted to account for the different types of recipes:

• Auto-learned: Unlock automatically on reaching a certain level in a craft, e.g. unidentified dyes.
• Sheet vendor: Unlock via purchasable consumable, e.g. certain exotic insignias and inscriptions, corrupt weapons.
• Mystic recipe: Unlock via mystic forge, e.g. trays of dessert recipes are learned by combining things in the forge.
• Holiday drop: Unlock via a drop during holiday or living story, e.g. some Halloween and Flame & Frost recipes. The recipes are available on the TP, but no longer drop.
• Standard drop: Unlock via a rare drop from chest or dungeon, e.g. Ashes of the Effigy.
• Forge only: Crafted in the Mystic Forge, e.g. Mystic Weapons. These recipes aren't learned or unlocked. You just have to know them, e.g. by reading the wiki.

There's often confusion about where to find or learn recipes and this would help clear it up, perhaps also by linking to the relevant section of Recipe, which probably needs to be rewritten to account for the above even if the template doesn't get updated. 75.37.18.88 06:00, 27 May 2013 (UTC)

This template needs a complete rewrite, I plan on doing that something this week. —Dr Ishmael 06:11, 27 May 2013 (UTC)

overhaul proposal

(original example thumbnail)

I've been working on an overhaul of this template, an overhaul which has been wanting since the BWEs began. You can find the template, along with the new CSS that it uses, at the page below. What you see at the right is a screenshot of what it looks like with the CSS, for anyone who doesn't feel like setting that up for themselves.

• User:Dr ishmael/Template:Recipe

The primary differences from the current template are:

• Doesn't look like an infobox. I mostly borrowed the style from GW2W.DE, and while I realize it doesn't really fit into our current design scheme, I just wanted to make it not an infobox, something that's been bugging me (and some other users) for over a year now. One big change is that it no longer displays its own icon, since the icon will (or at least should) always match the one in the article's infobox.
• Implements ideas learned from the API. E.g., required rating is a direct property of the recipe, not dependent on discipline, so it should be a single, distinct parameter.
• Uses #arraymap to replace the multiple discipline parameters.
• Implements semantics. This is something that should be done anyway, regardless of any redesign. In order to maintain the relationship between the properties for a single recipe on a page with multiple possible recipes, e.g. Minor Rune of the Adventurer, it creates a #subobject for the recipe, which is like a "phantom page" that only contains semantic properties. Subobjects can be returned from semantic queries just like normal articles, although there are a few extra considerations that we can deal with when we get to that point.

Feedback requested. —Dr Ishmael 21:41, 18 June 2013 (UTC)

I don't know if this happens, and you know the API much better. Can't the rating differentiate between crafting professions? - Yandere 21:13, 19 June 2013 (UTC)

Nope, like I said, rating is a single value per recipe, independent of disciplines. —Dr Ishmael 21:45, 19 June 2013 (UTC)

Cool. So the only thing I have to say... I don't really like the layout. It dosn't quite fit together with our other stuff. And since I sometimes look in the german wiki. It does look like a infobox to me anyways.

Another thing are the mystic forge recipes. Can we merge the two templates together or ist that something we can't do? - Yandere 21:53, 19 June 2013 (UTC)

Codewise, looks good. The id should be optional though or you'll get some bogus ids plastered everywhere :P

Formatting wise, I'd go with some brown colours closer to this (pic). Compared to the recipe infobox: its a slightly lighter brown, the heading font is smaller, the border between is lighter. I agree that the ingredient numbers should be regular font-weight.

@ Yandere, yeah the mystic recipe template could be combined with this one, I guess you'd wrap the top half of the template in a big if statement. (idk if mystic recipes have an id?) e.g.

{{#if: {{{id|}}}{{{source|}}}{{{type|}}}{{{discipline|}}}{{{rating|}}}{{{quantity|}}} |
<div class="wrapper">
...top half...
</div>
<div class="subheading">Ingredients</div>
}}

-Chieftain Alex 14:26, 25 June 2013 (UTC)

ID: I modified the JS to short-circuit if the ID span is empty, rather than generating a dummy link for ID=0.

Colors: I like yours.

Trollforge: You can probably simplify the #if to only check discipline, since that's required for all crafting recipes but should be undefined for MF recipes. The difficult part of handling MF recipes is generic ingredients. —Dr Ishmael 14:34, 25 June 2013 (UTC)

Ah well, i tried to combine templates :p I'd say it looks decent enough to switch it over. -Chieftain Alex 14:47, 25 June 2013 (UTC)

How are we intending to make the recipe/requires template work? (will it lookup recipes with the pagetitle as one of the ingredients?) And how do we query for recipes that aren't the first one? I've begun at User:Chieftain Alex/sandbox5 and [[User:Chieftain Alex/sandbox7]] but I'm not sure where to go next. -Chieftain Alex 17:06, 25 June 2013 (UTC)

Didn't look at anything yet. Property:Has ingredient will have 4 records containing a quantity and ingredient. The order of the records is arbitrary, you will be searching for a certain ingredient in the Has ingredient property: {{#ask:[[Has ingredient::?;<Item>]]}}. You'll get all pages with the item in the item field of one of the Has ingredient records set by the template.--Relyk ~ talk < 17:18, 25 June 2013 (UTC)

Great. [[User:Chieftain Alex/sandbox8]] :D -Chieftain Alex 17:33, 25 June 2013 (UTC)

Why are you arraymapping a list of #ask output into a single-page #ask? FTFY. —Dr Ishmael 17:53, 25 June 2013 (UTC)

Thanks for fixing that. (tfft?)

Can we apply a sort to the ingredients column? Even though we've got two pages producing the same sequence of "?Has ingredients", they're not in the same order, when they should be. -Chieftain Alex 18:04, 25 June 2013 (UTC)

I can't find anything on smw: about sorting the output of multi-valued properties, unfortunately. —Dr Ishmael 19:18, 25 June 2013 (UTC)

I've put together quite a crude template at [[User:Chieftain Alex/Templates/Alphabetical icons]] which seems to work (implemented in sandbox8). It uses quite a few parser functions per call :/ -Chieftain Alex 09:41, 26 June 2013 (UTC)

I've been watching you do that, and it's quite clever. As you say, though, it's quite a bit of code, and to have it run on every ingredient list in a long list of recipes - like for Jug of Water - might not be worth it. But I guess we'll have to try it and see.

My day job's been extremely busy for the past week, but I'm going to try and implement this proposal today - the formatting, if nothing else. —Dr Ishmael 12:43, 26 June 2013 (UTC)

Unsuprisingly it takes a silly time to load pages when it sorts them alphabetically using my template. Testing using Loaf of Bread (list of 11 items): 18 seconds with alpha-sort, 2 seconds without. /takes too long. (out of interest, the dpl version also takes 2 seconds - the same length of time as the unsorted) -Chieftain Alex 14:14, 27 June 2013 (UTC)

Generic results / mystic recipes

After looking at the dpl parm results of mystic recipe, I can see that there are only a dozen or so pages making use of the generic parameters - imo we could create a simpler infobox for these rare use cases - allowing us to use of the regular Recipe template (or something similar) for most cases. -Chieftain Alex 13:42, 26 June 2013 (UTC)

Sounds good to me.

I've implemented the new template. Backwards compatibility appears to be working properly. I made it so that the #subobject is only generated if the template has been updated to the new format - mostly because I was lazy and didn't want to extend the B-C to the subobject, but it also gives us an easy way to track which ones have been updated.

I realized that something I didn't mention above is what parameters are being removed in this update.

• The link and icon parameters are unnecessary for this template's intended purpose - to document the recipe to create the item whose page it is on. The icon will already be in the primary infobox, and the title in this template shouldn't link anywhere else.
• The various desc# parameters weren't used anywhere, so they're out.
• The vendor parameter doesn't really make sense in this box; if it's really desired, though, we can set things up to look up the vendor based on the recipe sheet name.

Next steps:

• Bot-edit every instance of this template to convert the discipline/ingredient parameters (and rename level to rank).
• Manually edit every instance to add type and source.
• Remove any instances of this template that are being used improperly (e.g. Copper Ore).

—Dr Ishmael 03:25, 27 June 2013 (UTC)

Why don't we simply add the generic funtionality to this infobox? This isn't much additional code. - Yandere 08:04, 27 June 2013 (UTC)

To help with the manual type/source additions, here's an Excel workbook with all recipe data from the API. —Dr Ishmael 18:13, 27 June 2013 (UTC)

some types always have a certain source 'refinement' and 'crafting components' are always 'automatic', 'upgrade components' are always 'discovery', etc. By the way for some reson google docs hates me, I can garantee you that I will encounter a wired bug or anything along the line. Well, at least this happens almost every time, when I try to use google docs with some friends of mine. - Yandere 18:35, 27 June 2013 (UTC)

You're correct on Refinement, but I think that's the only type like that. Some recipes of type Component and UpgradeComponent are learned from items (legendary Gifts are Component type). —Dr Ishmael 20:54, 27 June 2013 (UTC)

I just realized there's a major problem with the data behind that spreadsheet. The recipe constructor in my API module was failing to reset the discipline flags between recipes, so nearly every recipe had every discipline flagged. I fixed my code and I'm generating a new version now. —Dr Ishmael 15:52, 28 June 2013 (UTC)

I thought they were a bit odd, I was ignoring them anyway ^ -Chieftain Alex 16:10, 28 June 2013 (UTC)

Google doc has been updated. —Dr Ishmael 17:48, 28 June 2013 (UTC)

I've updated the workbook again. Now, instead of having to build the infobox yourself... EXCEL DOES IT FOR YOU! I've hidden all the columns on the "recipe" worksheet except for recipe ID, output item name, and the built-up recipe template. I also set it up with a macro, mapped to Ctrl+C, that enforces a "copy text only" functionality. Normally, if you copy a cell with linebreaks in it, Excel wraps it with double-quotes for pasting into text documents or forms. This is SUPER ANNOYING when you're iterating over infoboxes (trust me, I've done this A LOT in the past). This macro skips the quotes, so you can paste to the wiki without having to deal with them. —Dr Ishmael 23:34, 29 June 2013 (UTC)

Bot update and results

I've started the bot update to convert discipline/ingredient, remove icon/link, and rename level to rating. It's running for 100 edits first, after which I'll spot check the results before continuing. —Dr Ishmael 20:54, 27 June 2013 (UTC)

Looking good, will release the bot on full automatic. —Dr Ishmael 21:00, 27 June 2013 (UTC)

Complete, 2144 pages edited. I'll remove the BC code in a little bit unless Alex beats me to it. —Dr Ishmael 22:12, 27 June 2013 (UTC)

Heck your excel workbook is like a portable gw2db ;D - useful.

There are a few pages like Gift of Lightning which have name parameters still, and the odd "|exp" removed parameter, otherwise great work.

The next stages might be:

• To replace pages using non-generic invocations of {{mystic recipe}}.
• To review pages with multiple {{recipe}} invocations on one page - likely they will be listing recipes for other items, typical pages should have 1x {{recipe}} and 1x {{recipe/requires}} - these will need cleaning up by hand probably e.g. After those are done we can convert the recipe/requires to SMW, and bot remove all of the {{{1}}} parameters.

-Chieftain Alex 00:15, 28 June 2013 (UTC)

Most minor/major craftable runes and sigils have 2 recipes - one that uses 2x tier 1 or 3 rare materials and one that uses 1x tier 2 or 4 rare material. And there are some items that have different recipes for different disciplines, like Minor Sigil of the Night (some of these are not upgrades, that's just the only one I could think of).

I'd rather we create a new template under a new name to make an SMW recipe list, and let the bot replace the template completely. It shouldn't be a subtemplate anymore. —Dr Ishmael 01:14, 28 June 2013 (UTC)

{{recipe list}}--Relyk ~ talk < 03:42, 28 June 2013 (UTC)

Historical recipes

I think that the template shouldn't store the subobject if its used on a historical page. (e.g. Core of Flamestrike) thoughts? (either reference Property:Is historical or provide a historical parameter) -Chieftain Alex 09:48, 27 June 2013 (UTC)

I deliberately left the autocat code out, since Category:Recipes is pretty much pointless once we get all the recipes updated. I didn't think about using the same logic on the subobject - definitely needs it. —Dr Ishmael 12:35, 27 June 2013 (UTC)

Three ingredients or less bug

See Loaf of Bread. When the recipe only requires three ingredients or less, an error is generated. I'm going to wrap the subobject ingredients 3/4 in an #if statement. -Chieftain Alex 11:32, 27 June 2013 (UTC)

Ah, because there's always a static ';' generated even when the #explode and #sub don't generate anything. I extended that to ingredient2, since some recipes (non-alloy ingots, bolts, planks/dowels, and leather squares) only have 1 ingredient. —Dr Ishmael 12:31, 27 June 2013 (UTC)

Updated Template:Recipe DPL so that it still functions without breaking, apparently we need to leave the name parameter in though for it to work. -Chieftain Alex 12:38, 27 June 2013 (UTC)

Requiring name is no longer necessary. DPL passes a parameter {{{%PAGE%}}} that's like {{PAGENAME}} for the source page, and I updated the surrogate template to use it. —Dr Ishmael 13:05, 27 June 2013 (UTC)

Quantity default

personally I'd rather it defaulted to 1 than was blank. most of the recipes producing multiple results already have it set e.g. -Chieftain Alex 18:08, 27 June 2013 (UTC)

When we default it to 1 we have to set the property value to 1 per default, because leaving the value out will produce a proper result on the page but the property won't be set. - Yandere 18:38, 27 June 2013 (UTC)

I've set the default quantity to 1. Only 262 of over 7000 recipes have output_item_quantity > 1. —Dr Ishmael 19:10, 27 June 2013 (UTC)

Recipe sheet

User:Relyk/SMW/recipesheet to generate the recipe on the recipe sheet page.--Relyk ~ talk < 05:15, 28 June 2013 (UTC)

I don't see why. This box should only be used to show the recipe to make the item on the page, using it to show the recipe for an item on a different page confuses its purpose and is something I had hoped we would stop doing. You'd also have pages like Recipe: Gift of the Moon where you'd be showing both the recipe for *THIS* item and the recipe for *SOME OTHER* item. —Dr Ishmael 12:10, 28 June 2013 (UTC)

I'm re-using the code. People will want the recipe the recipe sheet gives on the recipe sheet page in one form or another.--Relyk ~ talk < 14:11, 28 June 2013 (UTC)

It's still showing the same box. The design semantics I'm striving for are: "This box shows the recipe to make this item." It's the same as an infobox: "This box shows basic data about this item/skill/etc." When we use the same box to show data about a different item, it breaks those semantics. And I'll repeat what I said above: recipe sheets that are themselves crafted would then have 2 boxes on the page with different semantics: "This box shows the recipe to make this item, but THIS box shows the recipe to make some other item." That's confusing to new readers. —Dr Ishmael 14:23, 28 June 2013 (UTC)

I know that, I'm re-using the code so I have an example for listing the recipe on the recipe sheet at all. I don't know if we want to list the recipe at all on the recipe sheet.--Relyk ~ talk < 18:25, 28 June 2013 (UTC)

Source left blank

Right now if the source is left blank, its blank on the page. It should indicate that the source is unknown if its left undefined, so editors know that they can add it if they know it. Near as I can reckon its a particular problem for the source field because it was added after the template was already in use, so lots of infoboxes don't have it defined. Could also make a category where any infobox without all fields filled in could be added. That worked pretty well for other wiki's I've been on. Psycho Robot (talk) 17:04, 28 June 2013 (UTC)

It'll be consistent with the rest of the wiki to display Unspecified.--Relyk ~ talk < 18:28, 28 June 2013 (UTC)

Ring suffixes

The canonical name is used to define the name of the item in the recipe subobject. We probably need parameters for recipes where items come with prefixes and suffixes--Relyk ~ talk < 18:36, 28 June 2013 (UTC)

No parameters necessary for that. See here: we would just reverse-query the subobject's parent to get the canonical name of the item. —Dr Ishmael 18:53, 28 June 2013 (UTC)

Oh, you grab it was Has subobject.--Relyk ~ talk < 19:05, 28 June 2013 (UTC)

Recipe subobjects for generic tables

See the current stuff on User:Chieftain Alex/sandbox2 → example: Destroyer Sword.

1. Would this be useful? I think so, as it means we could query for the recipe on the material pages to see what they're used for (e.g. will appear in Special:Browse/Destroyer-20Sword-23recipe1 and so can be used in the recipe list template)

   {{recipe list|Apothecary's Orichalcum Imbued Inscription}}

   Plus it handles the generic ingredient placeholder.
2. If thought ok, what would we call the template? My suggestion is {{multiple recipes}}.

-Chieftain Alex 22:47, 5 July 2013 (UTC)

That is so cool. By far the best solution I have seen so far for this mess. - Yandere 02:02, 6 July 2013 (UTC)

{{output recipe list}} >.> never mind, this is just creating multiple subobjects for recipes that only vary with insignia/inscription.--Relyk ~ talk < 03:00, 6 July 2013 (UTC)

The recipes kind of need their recipe ids though.--Relyk ~ talk < 03:08, 6 July 2013 (UTC)

Yeah, it's a lot easier to just make a page for every individual item, then use the output list on the summary page - just like we already did for runes and sigils. —Dr Ishmael 03:45, 6 July 2013 (UTC)

Easier as in create 13 pages for each item for their variant? Good one.

Editing 13x less pages works just fine for me. I won't personally be creating all those prefix-<weapon> pages. -Chieftain Alex 16:47, 6 July 2013 (UTC)

Ishy's proposal

(Reset indent) So I got to thinking (as I contemplated the prospect of adding 4.6k pages to the wiki for weapons/armor)... maybe Alex has a point here, and maybe I am nucking futs. So I built my own idea for crafted equipment tables.

• User:Dr ishmael/craft table
• User:Dr ishmael/craft table group
• User:Dr ishmael/craft table row
• Live example: Bronze Shield

It build subobjects for both the item and the recipe for each variant. Each recipe subobject has a special property "Has item data object" that links to the associated item subobject - this is to facilitate item data lookup in recipe lists (currently it's only canonical name and rarity, but we might expand in the future).

I chose a scheme of nested templates because of how the data is shared between the variants. I know this isn't the most user-friendly scheme, but it makes the most sense from a data perspective. They all share the same basic data of item type, crafting components, and discipline. Then you have groups that share additional data, including level, value, and rarity. At the lowest level, the only differences among the variants are the game IDs and the prefix (which determines the name, the activator ingredient, and the attributes).

Possible issues:

• I can't set data for {{Property:Gives attribute bonus}} in the item subobject. I can store the prefix name, however, with the nominal property name of "Has equipment prefix" (will be a text property).
• I am displaying the full recipe in each row, as opposed to the current practice of only showing the "activator" and giving a boilerplate recipe above the table. I never liked the current practice because it seems like it would be very confusing to new readers; however, I preferred it over the alternative of having to type out all ingredients in every row. My template can build the ingredient list automatically.
• I combined all the stat data into a single column: weapon strength, defense, and attributes. Since the ingredient list is already taking up vertical space, I figured I could save horizontal space by combining these. This probably won't be liked by everyone.
• I threw the chat links into the last column like that because I couldn't come up with anything better.

Now pick it apart, you goons. (I <3 you guys. :P ) —Dr Ishmael 20:33, 19 July 2013 (UTC)

Why not both individual pages and grouped pages? Is there any reason not to? Psycho Robot (talk) 18:21, 22 July 2013 (UTC)

The reason is that the individual item pages (over 4,000 of them) would basically be clutter - they have very little value on their own, with the real value being in the overview pages where a reader can compare the different variations. The only reason for the individual pages to exist is to provide data for the overview page, and previously, this seemed like the only viable method for storing the distinct item and recipe data.

I was always aware that we could potentially use #subobjects to store that data directly on the overview page without losing functionality, but I assumed the implementation would have to be extremely complex, i.e. even more hassle than creating 4k clutter pages. However, after working with recipe #subobjects for the past few weeks, and seeing Alex's initial proposal here, I realized that it could actually be implemented fairly easily. And now that I've written a prototype of this system, I've completely changed my mind about the "one-page-per-item" idea.

(P.S. This applies to weapons/armor only because they are highly uniform; jewelry has much less uniformity (each variant has a distinct icon, different rarities have different attached upgrade components, etc.), so it makes sense to keep individual pages for them.) —Dr Ishmael 19:44, 22 July 2013 (UTC)

Makes sense. As far as feedback of the example, I don't like how the attributes are indented. I think they should be lined up with the left edge of the stats. Otherwise it zig zags as you read through the page. You could zig, and you could zag, but zig zagging is stupid and dumb. Psycho Robot (talk) 21:35, 22 July 2013 (UTC)

I like it. Where would you document the upgrade component the item comes at creation? if it comes with one. - Yandere 21:42, 22 July 2013 (UTC)

@Robot: A valid concern, and one that is easily fixed with a line or two of CSS.

.table.equip dd { margin-left: 0; }
.table.equip dl { margin-top: 0; }

The first removes the indenting of the attributes, the second removes the extra space between the strength/defense and the attributes

@Yandere: None of the items I'm planning on using this for have an attached upgrade. —Dr Ishmael 21:45, 22 July 2013 (UTC)

So the weapons and the armors get one page like this but the jewelery gets seperate pages? correct?

By the way, why doesthe infobox not show that there is an unused upgrade slot on this icon? - Yandere 21:56, 22 July 2013 (UTC)

Right - as I stated in my P.S., jewelry isn't uniform enough to handle this way.

I assume you're talking about the infobox on Bronze Shield? Since the page is describing an entire set of items, and not a specific item, the infobox needs to be as generic as possible - all the details will be in the table. The infobox should probably only show the type, icon, and gallery, like it currently does.

However, you've sort of rephrased your first question: where do I state that all these items have an empty upgrade slot? I'd be fine stating that above the table (could make it part of the top-level wrapper template since it applies to all standard crafted items), or we could add it to the Stats column, but that would add even more vertical space to each row (esp. when you get up to triple-attribute items). —Dr Ishmael 22:22, 22 July 2013 (UTC)

Yeah I definitly see your point. I don't think it should be put in the table if it is identical for all items and yeah the vertical hight would probably become a problem. But the information should be listed somewhere on this page. Perhaps a sentence that all items are created with an unused upgrade slot for example. And sorry if I am incoherent, I have these terrible headaches for about a week now, and I think my communication skill starts to suffer a bit from these. - Yandere 23:37, 22 July 2013 (UTC)

I've added that to the top-level template. Feel free to fine-tune the wording. —Dr Ishmael 23:43, 22 July 2013 (UTC)

Another thought - if we were to use this type of table for jewellery and whatnot, presumably we would want to link to individual pages. Could the table be set to link to a page if there is one? If I recall from previous wiki stuff I've done, ifexist is an "expensive" function, so would it be too expensive to do this on, say, a page like Platinum Earring? Psycho Robot (talk) 00:04, 23 July 2013 (UTC)

As I've said already jewelry is completely different. Since we have the individual pages, the data is already on those pages, and we don't need templates like this to put the data on the overview pages. Instead we just use {{recipe table}} to gather the individual data onto the overview page. Here's the template code for Copper Ring:

{{recipe table
| min rating = 0
| max rating = 74
| discipline = jeweler
| type = Ring
}}

That's all we'd do for jewelry overviews. —Dr Ishmael 00:19, 23 July 2013 (UTC)

But you mentioned that overview pages are useful for comparing different variations on a specific type of equipment. For instance, if I wanted to get a platinum ring, I would want to go to Platinum Ring to look at what different kinds were avaliable. The proposed template would be much better for that than the recipe table, because it would provide info about the stats. The recipe and required rating would not be very important to me if I was going to buy one. Its important to be useful both types of players. Psycho Robot (talk) 05:12, 23 July 2013 (UTC)

I like this idea, especially with all the new Celestial weapons coming out. However, the lack of {{Property:Gives attribute bonus}} is troubling, since you might want to create a query for equipment that has an attribute at all (but want to exclude celestial). I suppose you could get around that buy just specifying prefixes, but that seems a bit clunky. As for the vertical listing of all properties, see how it looks with celestial, since that's the worst-case scenario. Also, how would this be applied to, say, dungeon equipment, where it's the same, but with different prefixes? --JonTheMon (talk) 23:21, 27 July 2013 (UTC)

Pretty intense solution, glad you came around to the idea of not creating all those pages :D

On formatting;

1. The stats section needs the left margin set to zero (as above - agreed)
2. I'd probably set the dl margin-top, margin-bottom to zero as well.
3. I'm not a fan of the (simple) or (master) suffixes - maybe bin those completely.
4. I'd be using recipe brown for the background colour scheme. (I really liked the formatting on the previous bronze shield layout ;D)

random thoughts;

• Afaik the rarity is "masterwork", so I'd rather the parameter for "User:Dr ishmael/craft table group" was class = Masterwork.
• Full recipe in each row is fine
• Last column is ugly, but theres no better way of doing it.

-Chieftain Alex 00:04, 28 July 2013 (UTC)

We could maybe do without the master suffix, but I think the simple suffix should stand because it differentiates the two items in a way that I feel is important. I agree that changing the rarity parameter to masterwork, but why not just have both? Would that be a problem? Lastly, after staring at it intently while sipping brandy and listening to Tchaikovsky, I think we should shuffle the column order so it goes Weapon - Rating - Ingredients - Level - Stats - Links - Value. I think we should do this because I just think it would look better with the vendor value at the end. The coin icon is like a period on the end of each row. Also, the level requirement and value are both very light columns and I think its nice to book end the more information dense columns with them. End transmission. Psycho Robot (talk) 01:10, 28 July 2013 (UTC)

Alright then:

1. I added {{custom CSS}} for this to User:Dr ishmael/craft table sandbox. Will add to MW:Common.css if we decide to implement.
2. See 1.
3. And your following bullet about "masterwork" - That's exactly why I called the parameter class instead of rarity: it's intended to map to the suffixes on the recipe names, since "(Simple)" in the recipe name is the only thing differentiating the non-inscription variant (as Psycho pointed out), and it's not a rarity name. I also need to include "Simple" as a value so that the determination of activator ingredient in the row template is fully robust.
4. We've got a mixed crafting/equipment table, so which color are we gonna choose? Does this need to go to a vote?

@Psycho: I've swapped the column order, see how you like it now. —Dr Ishmael 03:34, 28 July 2013 (UTC)

Yes, dance puppet! Do as I say! Could the crafting rating and level requirement be centered? I'm pro-centering of columns of regular length, as controversial as that opinion is. Psycho Robot (talk) 17:05, 28 July 2013 (UTC)

Shield table looks nice :) Can you add in how that recipe is obtained learned? (with link to the recipe sheet when there is one). Thanks. --Alad (talk) 17:46, 28 July 2013 (UTC)

(Simple) is automatic, tier 6 Celestial is recipe sheet, everything else is discovery. Hardly seems worth adding to the table, just include a note on the page. —Dr Ishmael 19:28, 28 July 2013 (UTC)

I misunderstood. I thought you intended to enter all craftable items. Many require recipe sheets to learn from. --Alad (talk) 05:00, 29 July 2013 (UTC)

No, this table is specifically for the "standard" craftable equipment that can be tabulated. Except for the Celestial equipment, everything else that is learned from recipe sheets is essentially unique, so they can't be tabulated and will just have a full infobox and recipe box, like Asuran Harpoon. —Dr Ishmael 14:12, 29 July 2013 (UTC)

Did you ever figure out a way to populate {{Property:Gives attribute bonus}} or will we just be limited to prefixes? --JonTheMon (talk) 14:27, 29 July 2013 (UTC)

You can't programmatically build properties within a #subobject, so you can't just say "If prefix=Berserker's then Gives attribute bonus=Power;179|Gives attribute bonus=Precision;128|Gives attribute bonus=Critical Damage;4". However, you can build the values of properties, and if the value is blank SMW ignores it - we do this for ingredients in Template:Recipe. I could do something similar here, but I'm scared of what the logic would look like: you'd have to set up one property assignment per attribute, and for the value you'd have to #switch over the known prefixes that include that attribute, then determine whether it's major or minor for that prefix.

| Gives attribute bonus={{#switch:{{lc:{{#var:ct_prefix}}}}|mighty|strong|vigorous|honed|pillaging|berserker's|valkyrie={{#var:major attribute}};Power|rejuvenating|rampager's|knight's|sentinel's|carrion|cleric's|explorer's={{#var:minor attribute}};Power}}

Something like that should work, but like I said, I'd have to do that for every attribute. —Dr Ishmael 14:57, 29 July 2013 (UTC)

I wonder if you could make a version of Template:Item stat lookup that would only output the values you want to set to Gives attribute bonus? Then just build the values of the properties from that? Ideally, you'd be able to use a single (delimited) setting of the properties, but I'm still hazy on things. --JonTheMon (talk) 15:42, 29 July 2013 (UTC)

Current version of SMW (1.18) allows this with a pipe delimiter (assuming I understand you correctly): | Gives attribute bonus = 179;Power|128;Precision|4;Critical Damage. Of course, that has to be a literal pipe and not {{!}}, so it would still be basically the same thing (you're just omitting the <property name> = portion). Next version 1.19 adds the | sep=, directive to use a custom delimiter for this. —Dr Ishmael 17:16, 29 July 2013 (UTC)

Oh, so you could generate that string, but the underlying problem is that #subobjects won't let Gives attribute bonus be set? You said it couldn't be programmatically built, but if it's mostly hard-coded and has just 1 value that's passed in, could it get properly set? --JonTheMon (talk) 18:19, 29 July 2013 (UTC)

Ishy's implementation

(Reset indent) After nearly 2 weeks of no new comments, I'm going to go ahead and implement this. 19 weapons and 18 armor pieces across 6 tiers isn't going to happen immediately, of course, so there will be opportunities for improvement as I go. Jon, I'm not abandoning your line of suggestion about the attribute bonus properties, but we can continue that later since it's not critical. —Dr Ishmael 20:23, 9 August 2013 (UTC)

In just under 2 weeks, I have completed the implementation of this template for all crafted weapons. This also marks the first time that we have had complete documentation of tier 3, 4, or 5 weapons.

I'll probably take a break from this tomorrow and get started with armor on Monday. —Dr Ishmael 21:46, 22 August 2013 (UTC)

Damn, I just remembered Destroyer weapons. I'll get those done before starting armor. —Dr Ishmael 21:15, 23 August 2013 (UTC)

Destroyer weapons done - Sentinel's harpoon gun showed up over the weekend, and I think I just missed the Rampager's hammer when I checked through them last week. —Dr Ishmael 15:54, 26 August 2013 (UTC)

Variable quantities

I have seen this:

You can transmute Crystalline Dust at a Mystic Forge.

Pile of Crystalline Dust

Mystic Forge ingredients

250Pile of Incandescent Dust
1Pile of Crystalline Dust
5Philosopher's Stone
5Mystic Crystal

The recipe gives 6-40 Piles of Crystalline Dust.

And now the question, how do I document the variable quantity. Is '6-40' a valid input for this variable? - Yandere 16:50, 8 July 2013 (UTC)

Awkward. 6-40 generates an error because Property:Has output quantity has to be a number, which we need if we want to query by volume amounts :/

I'd tentatively suggest we insert "| quantity = 6", and then we introduce an "upperlimit quantity" parameter to provide the top of the scale. -77.97.208.117 17:26, 8 July 2013 (UTC)

We're going to have a fully generic "clone" of this template, without the #suboject, for recipes like that. Since it can't be documented exactly, there's no point trying to shoehorn it into semantic annotations. —Dr Ishmael 17:51, 8 July 2013 (UTC)

I just wanted to ask, how do we call this clone template? And a secon point. These recipes are very common. The whole fine crafting material upgrade works on this basis. And I don'T think it wouldn't be to hard to incoperate these recipes in this template. Just as the anon suggested. Let the output be the minimum quantity and than define a [[Property: Has maximum output quantity]] which defaults to the value of output quantity.

Am I missing something dramatic why this wouldn'T be a working solution? - Yandere 19:52, 18 July 2013 (UTC)

Because quantity isn't the only thing that can be generic, ingredients can too. That's what I meant by a "fully generic" template: all inputs will be free-form wikitext, and it isn't going to create a subobject. Basically it'll be Template:Mystic recipe updated to this layout/format and with the genmat flags always 'Y'. —Dr Ishmael 21:38, 18 July 2013 (UTC)

Ah know I get waht you mean... But wouldn't that be an argument for incooperating such a thing, because the only generic thing in this case is the output and I think this happens a lot with mystic forge recipes. - Yandere 22:31, 18 July 2013 (UTC)

We also need a generic recipe template for recipe overviews, like recipe that only vary with the type of inscription in an armor recipe.--Relyk ~ talk < 22:26, 23 August 2013 (UTC)

Revisited

I converted, with the exception of invocations on Bottle of Elonian Wine, Crystal & Mystic Coin, all occurances of Mystic recipe to use this template. the remaining ones were wierd ubiquitous cases.

The converted few only have variable output amounts, so a parameter for upper limit quantity doesn't seem too crazy. {{{upper quantity}}}? -Chieftain Alex 00:15, 20 November 2013 (UTC)

I support that. There needs to be a better way to communicate variable outputs. Psycho Robot (talk) 00:19, 20 November 2013 (UTC)

I would rather you make it a separate property. ?Has output quantity should be a discrete property - it has a single value per recipe. Something like ?Has output quantity range (a record property composed of ?Has output quantity min and ?Has output quantity max, perhaps) would be more semantically correct for annotating a variable amount. —Dr Ishmael 01:04, 20 November 2013 (UTC)

(Edit conflict) Added the parameter. I didn't add any SMW annotation, although it would be useful to get it displaying in {{recipe table}}/{{recipe list}} as (x5-12). needs a property name, to then be added to the #ask, and then {{#if: {{{8|}}} |–{{{8}}} }} to be added to the result format.

or just query for quantity range as the doc says... -Chieftain Alex 01:08, 20 November 2013 (UTC)

Parenthesis in canonical names

The template doesn't save the parenthesis, even if they are part of the canonical name. These are all Infused equipment pieces for example. You can see the problem on this page: Gift of Ascension. - Yandere 15:20, 14 July 2013 (UTC)

Template:Recipe list result format was doing a blind #replace for '(' and ')'. This is needed because the output of a record property (like Property:Has ingredient) is formatted like 1 (Gift of Ascension). When the item name also contains those characters, that's when it caused a problem. I modified it so that instead of a blind find/replace, it specifically cuts off the wrapping parentheses in the #sub function. —Dr Ishmael 15:31, 14 July 2013 (UTC)

Yeah that makes sense. Thanks for the fix. - Yandere 15:45, 14 July 2013 (UTC)

PvP recipe

I just stumbled upon this template: {{PvP recipe}} Is the rank really a necessary information? When something requires a Deer Token than you obviously need a Deer Rank to get a Deer Token or am I missing something? Because if this is not a necessary it would be fairly easy to make a bot run and change all pvp recipes to this template. - Yandere 15:44, 14 July 2013 (UTC)

Technically, they're just Mystic Forge recipes - you can craft "standard" MF recipes at the MF in Heart of the Mists, so I'm pretty sure you could craft PvP MF recipes at the MF in LA. Rank is a property of the items, as you say, so we can convert these to MF recipes. —Dr Ishmael 16:45, 14 July 2013 (UTC)

changed the seperator in the one arraymap from comma to semicolen because of....

Item name with a comma in the name... Hurray! Solaria, Circle of the Sun Lunaria, Circle of the Moon - Yandere 04:05, 17 July 2013 (UTC)

That's fine. You could change the separator to "Logan is a pansy" and no one would care because it's entirely internal to that #arraymap function. —Dr Ishmael 12:49, 17 July 2013 (UTC)

I wasn't sure about that so I just wanted to state it. ^^ - Yandere 13:00, 17 July 2013 (UTC)

Logan might care, he's the sensitive sort. --Claret (talk) 22:44, 22 July 2013 (UTC)

Possible bug in Property:Learned from recipe sheet affecting Template:Item icon

Berserker's Darksteel Imbued Inscription is having an odd issue where

Code = {{#ask:[[Learned from recipe sheet::{{PAGENAME}}]]|link=none}} (Line:83@Template:Item infobox)

{{PAGENAME}} = Recipe: Berserker's Darksteel Imbued Inscription

Expected = Berserker's Darksteel Imbued Inscription#recipe1

Actual = Berserker's Darksteel Imbued Inscription#recipe1, Berserker's Darksteel Imbued Inscription#recipe1

As a result the discipline field for Recipe: Berserker's Darksteel Imbued Inscription is blank. --BryghtShadow (talk) 14:22, 26 September 2013 (UTC)

Edit: I should really look around more. //wiki.guildwars2.com/index.php?title=User_talk:Dr_ishmael&oldid=691025#SMW_Cache_.28again.3F.29 BryghtShadow (talk) 14:36, 26 September 2013 (UTC)

Mystic forge tonic recipes

(ok you lot know I don't own gw2 so i don't feel bad about asking) On pages like Eagle Raptor Tonic, the Mystery Tonic is listed twice. When put into the subobject, it ignores the second occurance (Mystic Forge#Tonics). (problem initially raised on talk:Mystic Forge)

Do you have to add the tonics separately, i.e. x1 and x1, or could you just add them both at once (x2) ... what I'm really saying is, can we change

{{recipe
| source = mystic forge
| quantity = 2
| ingredient1 = 1 Mystery Tonic
| ingredient2 = 1 Mystery Tonic
| ingredient3 = 1 Vial of Weak Blood
| ingredient4 = 1 Slab of Poultry Meat
}}

to

{{recipe
| source = mystic forge
| quantity = 2
| ingredient1 = 2 Mystery Tonic
| ingredient2 = 1 Vial of Weak Blood
| ingredient3 = 1 Slab of Poultry Meat
}}

without it being incorrect? Or do we need to add some special check to compare the recipe ingredients to make sure they're not the same, but if they are, add the amounts together when saving the subobject. >.> -Chieftain Alex 17:07, 20 November 2013 (UTC)

It more than likely means you need two separate tonics. The problem is you are mapping a property to a value and you have a collision (You can't have duplicates). It's working correctly as far as queries and what SMW is designed for. We would have to store them as separate values like runes or as a comma-separated list like tiers.--Relyk ~ talk < 17:18, 20 November 2013 (UTC)

(Edit conflict) Yes, they have to be added separately - every Mystic Forge recipe has to have 4 distinct ingredients. No, we can't collapse the ingredient list.

I suppose we'll have to add a dummy element to the Property:Has ingredient record with values 1/2/3/4 (based on the input ingredient# position) in order to keep every ingredient unique. —Dr Ishmael 17:21, 20 November 2013 (UTC)

Sorting key

Is there any way to add a sorting key to the recipe name in this template? The reason I feel there needs to be one is that I'd like to make a page with a list of mystic forge promotion recipes, and it would be best if it were sorted by type (cloth, metal, wood) then tier, instead of alphabetically by the resulting material name. Psycho Robot (talk) 22:03, 20 November 2013 (UTC)

The only way to sort on page load is to have a property with the values you want to sort by. Metal/cloth/wood doesn't correspond with any data on the page.. similarly even "tier" isn't SMW'd at the moment. Manual sort keys would require their own property.. and this might appear to be a confusing order. -Chieftain Alex 22:52, 20 November 2013 (UTC)

So there's no way to put an invisible string of characters in the existing name property to change how its sorted? I tried to do so here, but it didn't work. I thought something like this was used somewhere, so I thought maybe I just used it wrong. Psycho Robot (talk) 23:01, 20 November 2013 (UTC)

yeah the invisible string concept isn't entirely new, as far as I know its manual tables though. Idk how SMW handles hidden text (yet). -Chieftain Alex 23:11, 20 November 2013 (UTC)

you did manage to do it wrongly, as in you put the quotation mark before the style rather than after the equals sign.. | name = <span style="display:none">c2</span>Wool Scrap

so it is possible to put hidden spans in properties of Type "text", and it will sort by them if thats the chosen property, but that won't help with the existing tables since theres no way to limit the effects of the sort key to just one table. -Chieftain Alex 23:28, 20 November 2013 (UTC)

Sounds like its going to be more trouble than its worth, then. Oh well it was a nice idea in theory I think. Psycho Robot (talk) 23:46, 20 November 2013 (UTC)

Automatic recipe names differ from produced items

With the Sept 2014 update, a set of new "Ineffable" recipes have appeared. The title of the recipe does not necessarily correspond to the produced insignia, and it might be confusing to wiki users. Example: Recipe "Prime Ineffable Insignia (Level 68)" produces "Ineffable Intricate Gossamer Insignia." Normally the pattern is very consistent: "Apothecary's Intricate Gossamer Insignia (Exotic)" produces "Apothecary's Intricate Gossamer Insignia." But when the recipe source is not "recipe sheet," the name of the recipe is hidden. Because the new names are not so consistent, should the name of the recipe be shown even when it is "automatic" or "discovery"?

Use the name parameter, not sheet. —Dr Ishmael 01:54, 13 September 2014 (UTC)