Template talk:Item infobox/Archive 1

Adoption from GWW

This template is just a copy-paste from GWW but I think we need something more adapted to GW2. What are the elements we are supposed to show in this infobox? Also I think we need a convention about image format : jpg or png? --Till034 15:51, 20 August 2011 (UTC)

Well, we have Weapon infobox and Armor infobox, so I reckon we can easily design an item infobox to follow suit in this style. I reckon it won't need too much information, really; name, type, icon, value... Anything I missed? - Infinite - talk 16:07, 20 August 2011 (UTC)

I had a look, and I really loved this infobox design. I'd just add rarity. If we want something complete, we should add "stackable" and uses. We don't know a lot about consumables and salvaging, so we don't have to add it now, but I think we'd keep it in mind. --Till034 16:28, 20 August 2011 (UTC)

User:Till034/Sandbox2 I made the base. We must add more items types, and choose a bg-color.--Till034 09:26, 21 August 2011 (UTC)

Crafting items are a little bit of a complex subcategory if we want to get down to that level of granularity, and as per Till's note about salvaging/consumables we don't really know a lot about them yet. So far, there are basic crafting materials (which could be further subdivided), refined crafting materials, crafted items, upgrade components, crafting components, and crafting disciplines that could all be taken in mind. Redshift 00:03, 22 August 2011 (UTC)

I have just started doing the Sigil pages so am about to add Sigil to the template. Im not sure if Im ok to just edit it but we can always undo it if not. Titan Crow 10:18, 29 February 2012 (UTC)

Trophies

Can someone change this so that trophy items are added to the "trophies" category instead of "trophys"? Manifold 05:00, 9 March 2012 (UTC)

Done. --JonTheMon 06:06, 9 March 2012 (UTC)

Rarity

I would replace the rarity switch with

:{{ #if: {{{rarity|}}}|{{rarity|{{{rarity}}}}}|''Unspecified''}}

Is there anything that would speak against that? --zeeZ (talk) 13:31, 23 March 2012 (UTC)

If it's a 1:1 mapping, go ahead. But you might want to throw in a {{lc: somewhere. --JonTheMon 14:26, 23 March 2012 (UTC)

It more or less is, except it turns any non-matched parameter into Zcommon, if someone were to put rarity = cake...

Like so? :{{ #if: {{{rarity|}}}|{{rarity|{{lc:{{{rarity}}}}}}}|''Unspecified''}}

This probably applies to other templates that make use of rarity as well, like Template:Weapon infobox --zeeZ (talk) 14:35, 23 March 2012 (UTC)

Looks fine to me. But I can miss things, so may get another opinion or 2? --JonTheMon 16:03, 23 March 2012 (UTC)

This should work fine. Alfa-R 16:08, 23 March 2012 (UTC)

GWW concepts missing from infobox?

The GWW version includes these fields missing from this one:

• image = as it appears on the ground (vs icon, how it appears in inventory)
• stackable = whether it stacks (max amt?)
• campaign = not relevant here, but perhaps region might be useful (if relevant)
• uses = probably useful
• quest = there are quest-related items in GW2
• commonsalvage/raresalvage = some items salvage, others do not (system is more complex than GW1, so might follow different guidlines).
• render = probably useful for this wiki, too
• concept art (probably relevant)

There are probably also GW2-specific attributes/aspects that are missing. But I'm still getting the hang of it. – Tennessee Ernie Ford (TEF) 18:37, 28 April 2012 (UTC)

• Items can't be dropped on the floor, so they don't have such an appearance at this time.
• This should be added, I agree. Maybe include maximum amount of items in a stack, as well.
• Not sure if items are region-bound at all, actually. But if they are, yes.
• Yes. Should be added.
• Agreed. Should be added.
• Salvaging is a little more diverse than that, but we can find a way to document it anyway. Documenting different salvages would be a good idea.
• Not sure how we render objects that don't have an actual appearance in the world. Those that can be rendered probably should be. We need someone who can render objects like that then.

Nice to have our templates refreshed like this. :) - Infinite - talk 19:32, 28 April 2012 (UTC)

Updated list per Infinite's comments. (Forgot we can't drop stuff...yet or p'haps ever.) – Tennessee Ernie Ford (TEF) 22:07, 28 April 2012 (UTC)

BUMP! Uses - definitely want uses. Uses has lots of uses and I want to use it. — snograt 16:27, 14 October 2012 (UTC)

Mixing type...

I tried to sorted "type" and add new thing, but I ended up mixing all type categories... So now, for example, if you write in type "salvage kit", you get creature codex instead... I don't know how to change it back or make it works correctly. I need serious help :s. I feel really stupid now : / Lytalm 03:22, 29 April 2012 (UTC)

The sorting that was in place wasn't mindless or incorrect; it is how it's meant to be coded to work like it does. I temporarily reverted your edits to not cripple users when looking up item information.

That said, can you make a list of what should be added? Then we can discuss which things are valuable additions to the template, and which information is best left documented on the articles directly. - Infinite - talk 03:36, 29 April 2012 (UTC)

I wanted to add "boost" and "gathering tool" as articles in the section "type". Lytalm 04:16, 29 April 2012 (UTC)

Type and purpose association

If we look at the function of items, there were more types seen in the first BWE than covered by the infobox. The game is so complex that it would be helpful to newbies and veterans (once there are some) to see at-a-glance the utility of an item (e.g. know it's worth saving if one is a Tailor or that it's just merch food).

• There are multiple material types: common, rare, and refined. (The rare types don't follow rarity.)
• Multiple resources needed for crafting: the types of mats listed above; item pieces (e.g. Jute Glove Lining); add-ons (e.g. Runes), and non-material materials (e.g. Vial of Weak Blood, which is labeled as a material in-game, but has no material slot in storage).
• Merchant fodder are items that have no purpose except to generate cash (e.g. Broken Lockpick)
• Upgrade components fall into multiple types: Runes, Sigils, Jewels

I'm sure I'm missing a lot of other possibilities. – Tennessee Ernie Ford (TEF) 17:54, 30 April 2012 (UTC)

Bag features

Also missing from the infobox are features of bags:

• The number of slots.
• Any special features, e.g. newly found crafting items are automatically placed in a Craftsman's Bag (assuming it has slots).

– Tennessee Ernie Ford (TEF) 17:08, 5 May 2012 (UTC)

There seems to be a naming convention: "<#> Slot <special> <descriptor> <bag_type>". (I'm guessing that Craftsman's Bag is intended to be a generalized page and not a specific item.)

• <bag_type> depends on the discipline that crafts it: Tailors craft Bags, Leatherworkers craft Packs, and Armorsmiths craft Boxes. No effect on functionality.
• <descriptor> is something like "Leather" or "Reinforced Bronze", dependent on what materials it was crafted from. Not always present, and also seems to have no effect on functionality.
• <#> is the number of slots, determined by the specific Rune of Holding used in the recipe. [ref]
• <special> identifies the functionality. From what we have so far:
  • Invisible = items do not show up in sell-to-vendor lists and do not move when inventory is sorted
  • Oiled = junk items go here first
  • Craftsman's = crafting materials go here first.

There are probably other special features we haven't seen yet. Maybe we need a specialized infobox just for bags? —Dr Ishmael 18:58, 5 May 2012 (UTC)

Specialized infobox for bags works for me. – Tennessee Ernie Ford (TEF) 15:00, 6 May 2012 (UTC)

Is this still up to date? If it is, I will start coding, because the bag section looks really messy. - Yandere 08:18, 18 August 2012 (UTC)

Done: User:Yandere/Sandbox/Inventory_infobox

I will probably apply this to main space the next few days or so. - Yandere 20:18, 21 August 2012 (UTC)

Other Item templates

I spent some time looking to update pages with what the relevant effects were for each food.... Things got quite noxious with the example of Slice of Buttered Toast, which has effect x, if you are a, or b, or c.

That's me putting the same text on 4 pages. And if they rebalance the effect, thats me updating 4 more pages, on top of the skill.

Elsewhere I've seen implemented a (dunno what the proper term is for this) poly-template design for stuff/items
Implementation of this here would be simple:
On the item, start the template with: {{Item {{{1|infobox}}}
Then, you implement a template Template:Item Bonuses, and in the relevant slots on those pages, you add:
{{{Slice of Buttered Toast|Bonuses}}} and you get your Item Bonuses version of the template.

Is there a reason this hasn't been done, or has nobody gotten around to it yet? Torrenal 04:08, 10 May 2012 (UTC)

That's how the skill boxes work on GuildWiki, and it works because the skill infobox is actually a template separate from the article ([1][2][3][4]).

Once we get SMW installed and all the infoboxes annotated, that won't be necessary, as the description (and all other item details) will be stored in a property that can easily be queried from other pages. —Dr Ishmael 04:16, 10 May 2012 (UTC)

Sounds snazzy. No idea of the overhead it has, but sure sounds snazzy. Any sort of eta on SMW? Torrenal 04:48, 10 May 2012 (UTC)

In general, SMW is more efficient than DPL when generating similar lists, because SMW uses its own set of tables that are optimized for the properties and relationships it tracks. DPL queries everything out of MediaWiki's base tables and has to do extra parsing on top of that. ETA is unknown, but hopefully someone from Anet will give updates on the requests here. —Dr Ishmael 12:38, 10 May 2012 (UTC)

I bet we hear about those updates sometime after Arena-net completes their current stack of major tasks and has some breathing room. May be a bad bet, but its how I've seen these things work in other contexts. If I hear a go-live anouncement and those haven't happened, I'll look at using the poly-template design thingies where they make the most sense to me (which oddly, is not the example I used above). If it's something that SMW can do better and we move to it, I'm sure a bot could help with getting things converted. Torrenal 00:38, 12 May 2012 (UTC)

Need Multiple item TYPE

Some items are of multiple type like Food AND Crafting Material ie. type2 = crafting material Rudhraighe 21:08, 15 May 2012 (UTC)

SMW (specifically, Semantic Forms) will introduce a way to handle multi-valued parameters, so there would be no need for a type2=. It would probably be better to wait for that to get installed, instead of adding a type2= parameter now, updating all the necessary articles with it, then having to update them all again to a multi-valued type= when we get SMW. —Dr Ishmael 22:11, 15 May 2012 (UTC)

so i can either avoid adding the type2 = crafting material or break things by adding the ", crafting material" or ignore type altogether now and do all the fixes later ,,, i wish i knew more about bot editing and i could put a stump for the bot to find... i guess i'll let someone else do the work and just scream and complain about not having the proper type'S listed until i get so frustrated that i'll fix them later myself anyway... Please let me know when we get the SMW Rudhraighe 02:12, 16 May 2012 (UTC)

Item type for blueprints (WvW siege equipement)

Now the items type for blueprints is set at crafting material, but in my opinion this is not correct. Because it can not be used in crafting, as the other crafting materials are. If you look at the picture of the it sais below "Generic". So might it be an option to introduce a Generic item type for blueprints? Jurrit

Generic is added, so solved --Jurrit 16:33, 18 June 2012 (UTC)

Types of items — let's start from scratch at identifying the types

I think the game has a lot more item types than we currently identify. There are several threads above addressing this, but maybe we should try to make a comprehensive list of all the things that ANet and the community consider worth distinguishing first and then figure out how we want to categorize them via the infobox. For example, we have lumped "crafting material" into one type, but the game identifies several types. For starters, the bank divides them into general mats, fine mats, and food mats. Then the recipe lists in the crafting stations refer to refined mats, components, and insignias...each of which can be a "material" used in other recipes.

That doesn't require that we have 6 material "types", but it does mean we should find a better (and more intuitive) way to distinguish among them in the info box. – Tennessee Ernie Ford (TEF) 05:30, 14 June 2012 (UTC)

We do need the ability for a single entry to have more than one type some already have 3 types others can have as many as 4 or 5. Rudhraighe 10:43, 14 June 2012 (UTC)

That will be simple to do properly with SMW's #arraymap function. In order to future-proof the template and avoid the need for extra work once SMW is installed, I say we change the template temporarily so that it does not auto-link the item type parameter. Once that is done, you could set | type = Food, Crafting material, Ingredient on the item and it would display all of them. The drawback of this is that, until we get SMW, the item types won't be linked when displayed in the infobox, and they couldn't be auto-categorized, either. However, once SMW is installed, all we have to do is update the template, and everything will work. *I* think it's reasonable to let things work that way for the interim, but others may see it as completely broken.

Anyway, a list of item types, with a rudimentary list of properties (I'm not listing any stats due to pretty much all of them scaling). Anyone can add to this list. —Dr Ishmael 14:52, 14 June 2012 (UTC)

List of item types

(per Ish, ok to edit)
- I revised the list quite deeply —Faalagorn☎/✓

Equipment

• Weapon (weapons are sorted by the type, it's useless to sort weapons to melee/ranged or martial/magical, because it all depends on profession - axe is a ranged weapon for ranger and melee weapon for warrior, while dagger is a martial weapon for thief and magical for elementalist). I loosly based on weapon article to sort them (types are alphabetically, and order is either hand -> offhand only -> two handed. All aquatic weapons are two handed, so no need to split these. Enviromental weapons are a specific cause.
  • Regular weapons
    • One-handed weapon
      • Axe
      • Dagger
      • Mace
      • Pistol
      • Scepter
      • Sword
    • Off-hand weapon
      • Focus
      • Shield
      • Torch
      • Warhorn
    • Two-handed weapon
      • Greatsword
      • Hammer
      • Longbow
      • Rifle
      • Short bow
      • Staff
  • Aquatic weapon
    • Harpoon
    • Spear
    • Trident
  • Environmental weapon
• Armor (the main sorting is by armor type (or class), but armor needs at least one more property - slot (TP names are in paranthesis): head (or helm), shoulders, chest (or coat), arms (or gloves), legs (or leggings), feet (or boots) and aquatic helm (or breathing apparatus, but I don't know where these term orginated from)). I suggest splitting them by slot they come to becuase not all head armors are helmets, not all chest armors are coats, not all hands armors are gloves, not all legs armors are leggings, and not all feet armors are boots. Fortunately, all professionalism wear "Aquatic Helms", they are only "light", "medium" or "heavy". All armor parts except for aquatic helms also have 1-3 dye channels or slots.
  • Light armor
  • Medium armor
  • Heavy armor
• Accessory (or Trinket) Back slot is arguable, but it still sits on the accessory section of the Hero screen, and "back brace" for example can be treated as an accessory IMO. I sorted them in order of importance, but they are sorted as they appear in-game in Hero scren.
  • Amulet
  • Ring
  • Earring (or Accessory)
  • Back
• Bag
  • slots ([number]), bag type (invisible, equipment, junk, crafting materials)
• Gathering tool
  • tool type (axe, pick, sickle), tool quality (rough, iron, etc.) (these could also be called consumables) it's hard to classify them as consumables, since they need to be worn in order to use them. They are hard to qualify as equipment, even if they are "worn", so they best fit at the separate category.
• Town clothing
  • Head
  • Chest
  • Arms
  • Legs
  • Feet
  • Toy

Equipment upgrade

• Sigil
• Rune
• Gemstone and Jewel (they are also a crafting materials)
• Doubloon (also a crafting material)
• Mark, Talisman, Seal, Medallion , Crest (they need a common name)
• Core (aren't they removed content?)

Crafting

• Crafting material
  • Basic crafting material (these can be further split into "raw" materials, "refined" materials and maybe even "additional" materials for materials that are bought from crafting NPC (spools and lumps) but I don't know if that's needed. Materials are also tied to the crafting disciplines and levels as well as tied to "tiers" 1-6, so they can be split based on that. Gemstones, Jewels and Doubloons are also an upgrade components.
  • Fine crafting material
  • Rare crafting material
  • Ingredient
  • Gemstone and Jewel
  • Doubloon
  • Crafting component I'm not 100% sure about this, as I only done leatherworking, so I don't know much about cooking or jeweler intermediate products (if any).
    • Regular crafting component (parts of armor or weapon)
    • Seasoning, "Mixed Ingredient" (e.g. Bowl of Stirfry Base) [these are the cooking analogies to crafting components)
    • Inscription
      • inscription type (festering, honed, etc.)
    • Insignia
      • insignia type (festering, honed, etc.)
• Mystic item

Consumable - these items disappear after double clicking on them. Are "consumed". Various consumables (nourishment, alcohols, manuals, recipes) are tied to character level, while recipes and nourishment are also tied to professions and professions levels, as well as tiers 1-6

• Package (or Container) - TP list them separate from consumables, and that may be quite accurate, because some other item is given in return, you don't "lose" anything by consuming them
• Boost
• Nourishment
  • Food
  • Maintenance Oil
  • Potion
  • Tuning Crystal
  • Sharpening Stone
• Alcohol
• Salvage Kit (they are quite "unique" consumables, as they have "uses" that works similar to stacks, but not quite - can't be split and merged. Kinda similar to gathering tools, but they work by simple double clicking on them, unlike gathering tools which needs to be equipped
• Manual (or Trait Guide)
• Blueprint
  • normal
  • upgraded
• Recipe
• Dye
• Tonic and Hylek Potion ("Festive")
• Tray
• Skin (PvP, HoM and Halloween weapon/armor skins for example )
• Transmutation Stone
• Items that grant bundle upon using
• Various other consumable items that aren't tied to any category - like Tome of Influence, Chalice of Glory, Black Lion Key, Instant Repair Canister, Revive Orb, Evon Gnashblade's Box o' Fun, Cow Finisher or letters

Gizmo - similar to consumable but are NOT used up after use. Might be time limited (Golem Banker)

Trophy

• Junk
• Token
  • Dungeon tokens
  • Other tokens (Badge of Honor for example)
• Salvage item
• Event item
• Items used to complete Hearts - similar to "event items" but without the tag

Other

• Miniature
• Creature Codex
• Story item (these are only visible in Hero's window personal story tab

Further discussion (re: list of items)

There were also a few i don't remember from the Trading post Sort Engine Rudhraighe 15:28, 14 June 2012 (UTC)

The Trading Post Breakdown of Item Categories Subcategories and Rarity With Color Code Chart

Rudhraighe 20:42, 29 June 2012 (UTC)

Oh, I didn't realized that there was a discussion already about item types, luckily I went to talk page after seeing how item types are not outdated and not comprehensive in the infbox. I made a list of items by type while updating Item page, so take a look there. BLTC list is a good place to start indeed, but it's hard not to agree it's not much accurate either, especially since it have redundant categories after updates (for example, you can't sell gathering tools anymore).

I also updated Ish's list a bit, see changelog of what I changed, and tell me if you disapprove anything from the edits I've done to it.
Faalagorn☎/✓ 13:36, 22 October 2012 (UTC).

Costs in multiple currencies

A few items (e.g. Tomato) are sold from multiple vendors and have costs in multiple currencies. This causes a number of minor formatting issues no matter how the values are entered. People are trying to create work-arounds on the fly, but none of them look very good in my opinion.

I propose we handle this by adding cost parameters to {{item infobox}}, {{armor infobox}}, and {{weapon infobox}} for each currency to the template, specifically:

1. Missing currencies: Cost-karma, Cost-supply, cost-gems, cost-glory
   Entering any of these creates a new line and automatically displays the currency symbol, e.g. cost-karma = 3 results in 3.
2. An alternative to cost: cost-coin.
   Overrides cost, entering cost-coin = 5 produces 5 , cost-coin = 205 produces 2  5 , and cost-coin = 10205 produces 1  2  5 .

This has several advantages over the current system (a single cost parameter):

• There will never be a need to kludge the formatting inside the infbox, which always leads to issues.
• It will be easier to use DPL (and ultimately SMW, when converted) to compare items of similar costs in a particular currency.
• It's unambiguous about what we mean by the parameters.
• For legacy support, we keep cost as is.

I've left out influence, since that cannot be used to purchase items, armor, or weapons. I also didn't address the few items known to have multiple costs in a single currency (e.g. Instant Repair Canister)— I suggest we handle that on a case-by-case basis for now. Tennessee Ernie Ford (TEF) 17:19, 20 June 2012 (UTC)

I don't know why we have cost in the infobox at all - it doesn't seem very useful unless you also know where you buy the item for that price. It should be listed under an Acquisition section along with the NPC name. —Dr Ishmael 17:57, 20 June 2012 (UTC)

List cost or price? One thing that becomes very ambiguous is: is that how much it costs me to obtain the item from a merchant, or is that how much the merchant pays me when I sell them to him. I would, for consistency, list the price-for-selling-to-the-merchant (aka - price) in the infobox. I would then list expense for obtaining the item (aka - cost) in the 'how to obtain' section of the main article. This circumvents needing multiple costs in the infobox. This gets around the issue where the same item may have a multi-currency price (say, 20000 PvP currency plus 20 gold). This reduces the cost/price confusion. If you need to embed info for SMW, then you could use templates not unlike my the Template:Inventory/ section I put together, and embed the prices from there. Torrenal 18:39, 20 June 2012 (UTC)

'price-for-selling-to-the-merchant' is what is currently listed in the | value = parameter, and I think that's perfectly fine - we should expect that any non-scaling item should have a fixed sell value. (Scaling items or randomized loot, obviously, will have random values.) I agree with everything else you said. —Dr Ishmael 19:18, 20 June 2012 (UTC)

I hate to bring up GWW, but there are items there that have multiple buy costs, but only 1 sell price (e.g. gw1:Superior Salvage Kit) and there we have an acquisition section for the buy prices. We could standardize that and have a template and properties for the buy prices, but I'm unsure about that. --JonTheMon 20:14, 20 June 2012 (UTC)

That's exactly what I was thinking of, but like you, I know that saying "we did it that way for GW1!" will often lead to people dismissing an idea out of hand simply because "we do things different here". —Dr Ishmael 20:19, 20 June 2012 (UTC)

Well, at the very least it's a good example of the system you would want to implement. --JonTheMon 20:25, 20 June 2012 (UTC)

Are there any items which can be sold to a vendor or player with less than 100% uses remaining?Sal kits and gathering tools become soulbound on use. Are there any that have multiple prices when purchased from vendors (outside the difference in currency that this is meant to address). I prefer using the infobox when possible (because it's easier to do DPL/SMW research that way), but if it turns out there's too much data to fit reasonably, I'm okay with adding a standardized acquisition section. At the moment, it seems like an unnecessary step. – Tennessee Ernie Ford (TEF) 20:31, 20 June 2012 (UTC)

Gathering tools are stacks, right? i.e. you can combine a stack of 25 and a stack of 20 to get a stack of 45. For those, we would show the value of a 1-item stack, just like any other stackable item.

Salvage kits are similar to stackable items, with the key difference that you can't combine multiple instance of a kit into a single stack. I think for them we should list the value of a 1-use kit, then simply have the infobox do: ;Value :{value} {ifeq {type} | kit | per use} to make it clear.

"Are there any that have multiple prices when purchased from vendors?" I don't think we have enough information yet to give a definitive answer to that question. It still makes more sense to me to list the item's cost(s) alongside the list of the item's vendors, instead of separating them. —Dr Ishmael 20:42, 20 June 2012 (UTC)

Gathering tools and salvage kits do not work like stacks from the player's point of view: they cannot be combined or split — I think it's a misleading use of the jargon. But in any case, you cannot sell either after they are used. A 24-use salvage kit has zero value at a vendor, so I think we can ignore it and focus on the actual items sold, a 25-use kit or a 100-use gathering tool.

In contrast, you can only buy spools of thread in stacks of 10; if you use 1, you can sell the remaining 9 to a vendor. For those items, I do agree we should list the per unit cost (and add an acquisition note that they only come in stacks of 10 from vendors) – Tennessee Ernie Ford (TEF) 21:09, 20 June 2012 (UTC)

(Reset indent) OK, let me rephrase this: are there any objections to updating this template to use a separate cost parameter for each relevant type of currency? (The arguments are at the top, but basically this will prevent the current amount of kludging that is going on to list costs for items that can be bought for karma or coin; it will have less impact on other costs.) – Tennessee Ernie Ford (TEF) 02:18, 1 July 2012 (UTC)

Yes, my objection still stands: I don't think we should have cost parameters on the infobox at all. It belongs in the acquisition section of the article. —Dr Ishmael 03:06, 1 July 2012 (UTC)

But we do have an infobox that does have a cost parameter. As long as that's true, we should have multiple parameters, no?

Why does it make more sense, in your estimation, to only list costs as part of acquisition? Isn't cost is as much an inherent trait of the item as is value or type ? The only difference is that cost isn't displayed in the game except in the vendor interface, but it's stored in the game as just another parameter.

My main reason for preferring cost to be in the infobox is that allows us to run DPL queries easily; putting costs in the acquisition section prevents us from running queries. – Tennessee Ernie Ford (TEF) 03:19, 1 July 2012 (UTC)

For the reason Jon gave: it's possible that different merchants might sell the same item in the same currency at different prices. We don't have enough data to say for certain that this won't happen. For querying, format the acquisition as a table and make a table row template. —Dr Ishmael 03:44, 1 July 2012 (UTC)

If you choose to use cost in the infobox than I would also like to add "Badge of Honor" for cost, for WvW blueprints.--Jurrit 13:07, 16 August 2012 (UTC)

At the moment Cost is a blank text parameter. You can write whatever you want into the parameter. It doesn't have an inherent logic to it unlike value. So just write cost = x Badge of Honor and it will show up in the infobox just fine, no need to edit anything in the default parameter.

By the way I have to agree with ishmael. I am currently on my way to standarize the infoboxes. The cost parameter (as well as the value parameter) were always problematic. The value paramter is now fixed, because it uses the value template and will not acept wrong input.

The cost paramter on the other hand can be as complex as it wants to be. 4 merchants can sell an item: two for gold, one for glory and one for karma. The gold prices don't have to be identical. So you would have two write all the information in the cost parameter. - Yandere 19:56, 16 August 2012 (UTC)

Gathering tool vs. Crafting tool

They both link to the same article (Gathering tool) and auto-categorize as gathering tools too, why the parameters section says they're separate/different from each other? – Valento ^msg 21:18, 24 July 2012 (UTC)

Accessories

How about putting in an Accessory type? They're not armor (no defense), this seems the infobox to use. Wombatt 03:28, 27 July 2012 (UTC)

It's a bit late and you've probably found Template:Accessory infobox by now. But just in case someone else has the same question. -- ab.er.rant 04:47, 8 September 2012 (UTC)

Bound-ness

There's currently no link to Account Bound for such items. It looks kinda odd to have the infobox say "Soulbound Account Bound", too, since Account Bound isn't a subtype of Soulbound-ness. Perhaps just change it to say one of the following:

• Soulbound
• Not Soulbound
• Soulbound on acquire
• Soulbound on use
• Account Bound

Manifold 17:33, 28 October 2012 (PDT)

I support this, just "Soulbound" alone isn't required - everything either binds on aquire or on use (equip) - it's easy to check too, just post the item into chat and hover your mouse over description.
—Faalagorn☎/✓ 14:26, 14 November 2012 (UTC).

We need a new word to indicate bound-ness. I suggest bondage. — snograt 16:30, 14 November 2012 (UTC)

+1 more bondage in boxes. --Chieftain Alex 17:03, 14 November 2012 (UTC)

I don't like it... I guess my mind is too perverted ._.
—Faalagorn☎/✓ 22:16, 14 November 2012 (UTC).

We could just have the field be called "binding" and have soulbound, not, acquire, use, account be the options. --JonTheMon 22:28, 14 November 2012 (UTC)

What's the practical difference between "soulbound" and "on acquire"? If an item in a vendor list says "Soulbound on acquire," I think we should document that as simply "Soulbound." The "on acquire" part isn't necessary, since you'll never possess the item in this state. —Dr Ishmael 22:34, 14 November 2012 (UTC)

(Reset indent) On a side note, where exactly is the switch statement doing all the work for this bound parameter, seeing as I cannot find it in the code? :3--Relyk 22:59, 14 November 2012 (UTC)

{{Default item parameter}}

;[[Soulbound]] 
:{{#switch: {{lc:{{{bound|}}}}}
|u|on use|on Use|use = On Use
|on acquire |on Acquire|acquire = On Acquire
|n|no=No
|a|account = Account Bound
|y|yes|#default =Yes }}|}}

ps you're bad for not finding it. lol --Chieftain Alex 23:08, 14 November 2012 (UTC)

You know, this isn't the {{Default item parameter}} talk page in the first place, so I have an excuse.--Relyk 09:31, 15 November 2012 (UTC)

May I suggest - Soulbound: On acquire/On use/no. Account bound: yes/no. Simplicity rules. — snograt 11:51, 15 November 2012 (UTC)

An item can't be both Soulbound and Account bound, they are different types of bondage... sorry, binding. So making them separate parameters is misleading. —Dr Ishmael 13:35, 15 November 2012 (UTC)

An option to omit the field, then? OR Bound:Aq|Us|Ac|no where ac would labal it as bound on acquire, us for bound on use, ac would display account bound and no would indicate not bound at all. "Bound on acquire" annoys the pedant in me (yes, again) as it should be "bound on acquisition" but meh. Oh, obviously all the previous was written by somebody with no idea whatsoever about how templates etc. work and to whom SMW will forever be Super Mario World. — snograt 14:43, 15 November 2012 (UTC)

That's essentially what I was going for, and Relyk has already modified the subtemplate to work that way. —Dr Ishmael 15:11, 15 November 2012 (UTC)

Gifts

I was going to edit myself, but there seems to be more going on than I understand. Could someone please add gifts as an item type? Manifold 22:42, 1 November 2012 (UTC)

Done. —Dr Ishmael 00:10, 2 November 2012 (UTC)

Gallery

Any reason why the images are restricted to only show for specific types? (I'm looking at the Greatsaw Greatsword Skin page, and it needs a gallery but its a consumable.) I'd propose the removal of the switch statement that checks for specific types, or the alteration that the gallery must exist if "gallery1" is defined. --Chieftain Alex 09:47, 7 November 2012 (UTC)

I was also wondering why this is. I wanted to add Gallery images to the infoboxes of Tonics, but it won't work because of this restriction. Seems that at least Skins and Tonics should also have gallery images so you can see what it looks like. 08Ray 16:54, 7 January 2013 (UTC)

It's restricted because things like trophies and most non-tonic consumables don't have any appearance that can be documented in a gallery, so there's no point in showing that section for those item types. I can add tonic to the list of types that have a gallery, but I don't want to add the generic consumable because, as already noted, the majority of consumables don't need it. I guess we'll have to define a new subtype for skin consumables. —Dr Ishmael 17:09, 7 January 2013 (UTC)

Stackable

is there some reason why this is left for notes rather than the infobox? can't run queries from the notes. 75.37.20.148 17:49, 10 February 2013 (UTC)

Bringing this up again because of this discussion. Any reason why we don’t have that? poke | talk 16:56, 20 July 2013 (UTC)

I agree. Let's at least discuss it. I would add it, but I don't know how. Daddicus (talk) 19:49, 21 July 2013 (UTC)

Icon Binding

I have just added my first "Recipe:" to the wiki and found that i had to use icon = Recipe Sheet.png string to get the sheet icon even if i defined type = recipe . Is this intended? Magistrella 20:28, 15 February 2013 (UTC)

Recipe is shorthand for recipe sheet; recipes aren't a type of item--Relyk ~ talk > 20:42, 15 February 2013 (UTC)

Nourishment

User:Relyk/sandbox/nourishment fully implements the nourishment fact for all the nourishment. The duration is in minutes and converts automatically so you only need supply a number. There is always a primary and secondary effect and the +10 xp per kill effect, so we can parametrize it. The template is getting stuck in the description when it should be in the variables parameter, which can be changed to nourishment. The template needs to change icon based on the nourishment type, so it makes more sense to embed the template into the item infobox with the nourishment parameter. And so on--Relyk ~ talk > 04:40, 16 May 2013 (UTC)

Some display +10% experience from kills. Although as far as I know, that's the true effect of all them. Edit: And ice cream has a karma bonus instead, and I think a couple have +15% experience. Manifold 04:51, 16 May 2013 (UTC)

Remove it from the default then. It would have to be named anyways since some items only have a single effect. Can always use #arraymap, but seems excessive when there's always 2-3 effects.--Relyk ~ talk > 05:00, 16 May 2013 (UTC)

Consortium Swim Speed Boost uses the same layout, so a more general name for the template would be handy so we don't possibly have to change the parameter name again in the future. A fact parameter to match the discussion on the skill infobox will work.--Relyk ~ talk > 08:56, 16 May 2013 (UTC)

Tokens

Why are we categorizing them as trophies? All tokens are trophies, although they are just stuck under items right now.--Relyk ~ talk < 02:02, 2 June 2013 (UTC)

Categorizing them just as tokens would be odd given that all trophies should be categorized together (otherwise it makes not much sense, right?). Maybe we can just change the token category to be a subcategory of trophies and then remove the additional trophies category from the articles because all tokens will be categorized as tokens, and tokens are trophies. poke | talk 05:50, 2 June 2013 (UTC)

Flavor text

We need a parameter for the blue quoted text that appears are certain items (whatever it's called) in all the item infoboxes. Unless we're fine just putting it in plaintext under the standard description.--Relyk ~ talk < 04:20, 12 June 2013 (UTC)

The game treats it all as one string. They use a custom <c> tag to mark text for different colors:

• Mad Memoires: Complete Edition API

"description":"A recollection of the life and deeds of Mad King Thorn, as told by his loyal subjects and friends. Contains a complete account of King Oswald Thorn's life, from boyhood to gruesome death.<br><c=@flavor>\"Even after death, I shall return! And all my enemies will burn, burn, BURN!\"<br>—Mad King Thorn</c>"

• Superior Sigil of Rage API

"description":"10% Chance on Critical: Gain Quickness (3 Seconds)<br><c=@reminder>(Cooldown: 45 Seconds)</c>"

<c=@x> is essentially equivalent to <span class="x"> in HTML/CSS.

For GuildWiki, I wrote a custom extension to support easy updates to skill descriptions by a bot script that would copy the strings directly from the Gw.dat text files; part of its function was to convert <c=@SkillDull>...</c> to ''...'' (and Common.css then had rules for that <i> tag to be colored gray). Here, for GW2W, I don't know that an extension is the right choice (it's probably overkill). Simpler solutions would be to either A) use the raw description from the API with #replace functions in the infobox template, or B) manually perform the replace and use wikicode/HTML directly in the infobox input. —Dr Ishmael 04:52, 12 June 2013 (UTC)

If anything, only B. The raw text is never visible to normal players, so this would only confuse everyone trying to manually edit an article. poke | talk 09:53, 12 June 2013 (UTC)

Recipe sheets

I think reciep sheets are poorly documented by this infobox. This is the first an a typical example of a Recipe sheet: Recipe: Berserker's Intricate Gossamer Insignia

First I would suggest to move recipe sheets to the Template:Crafting infobox because we can use the 'Used by' logic to list the information currently listed under 'Req. level'. There already is a workin logic for this and I think we should put that to good use.

Secound thing: Most of the information can and should be automated. 'type = recipe sheet' usually sets the icon of the infobox as well as the type obiously but it can also parse the categorisation key from the name, because you just have to get the pagename without 'Recipe:'.

We could trim most infoboxes and get a working autocategorisation in this section again. Of cause moving every item in the category form item infobox to crafting infobox, is a bot task. The logic of the second point shouldn't be to hard to implement. Trimming the infoboxes and populating the crafting discipline parameter will be the most work.

Thoughts? - Yandere 13:19, 18 June 2013 (UTC)

I think we need to completely overhaul the item infoboxes. Now that we can see how things are presented in the API, which is the closest we have to the in-game representation of the data structure, the best approach seems to be to have a single "portal" infobox (this one) that then calls subtemplates to handle specialized data for the different item types; in other words, an inversion of how we currently have them set up (lots of different infoboxes that all call {{Default item parameter}} to handle the common data).

Specific to your question, however, the disciplines that can use a recipe sheet are identical to the ones that can use the recipe, i.e. the disciplines are a property of the recipe. Even in the API, recipe sheets don't show this data [5], it's shown on the recipe [6]. So what we need to do is get recipes sorted out with SMW and stuff, then we pull that data onto the recipe sheet page. That's something I've been trying to work on, and I have a new recipe template proposal that I need to actually propose. —Dr Ishmael 15:56, 18 June 2013 (UTC)

Ah that is cool and it would sort out a lot of problems. So basiclly we delay this overhaul until the Recipes got an update. - Yandere 12:32, 19 June 2013 (UTC)

Post {{Recipe}} update

Some recipe pages, such as Recipe: Berserker's Intricate Gossamer Insignia, have the level parameter filled out with discipline reqs, should we create something like a discipline parameter, and arraymap the input? -Chieftain Alex 15:36, 10 July 2013 (UTC)

So basically the problem is that it shouldn't be storing what is a essentially a discipline level req under the "level requirement" property.. which seems to be a level req to wield and use items.

The problem lies with the {{Default item parameter}} template, which tries to SMW the level. I'd like to suggest that we either don't use the default item template for item infobox, or that we create an alternative option based on a {{{type}}} input.

The third (and simplest) solution that I came up with would be to add the following to default item param.

{{#if: {{{level}}} |
;[[Character#Progression|Req. level]]
:{{#ifeq: {{lc:{{{type}}}}} | recipe | {{{level}}} | [[Has level requirement::{{{level}}}]] }}
}}

Which requires no bot (yay!) (i.e. it sees that its a recipe, and gives up trying to SMW the value) -Chieftain Alex 17:42, 12 July 2013 (UTC)

{{#ifeq:{{{type}}}|recipe sheet|
;[[Discipline rating]]
{{#vardefine:rating|{{#show:{{{1|}}}|?Requires rating}}}}{{#arraymap:{{#show:{{{1|}}}|?Has discipline}}|,|@@@|<Stuff> ({{#var:rating}})|<br />}}
}}

Ishmael mentioned this earlier, the discipline and rating are properties of the recipe, not the item. The recipe sheets have a level requirement to use in addition to disciplines. The discipline and rating info is pulled from the recipe subobject.--Relyk ~ talk < 18:00, 12 July 2013 (UTC)

Relyk's right, storing required disciplines in the item infobox is backwards. They are always properties of a) the recipe this item unlocks (for recipe sheets), or b) the recipes this item is used in (for ingredients). Until now, unfortunately, we didn't have a feasible method of looking up that data, thus we were forced to store them explicitly in the infobox anyway.

Now, however, it's trivial (as Relyk showed) to lookup the required disciplines of the recipe that a recipe sheet unlocks. Relyk's code (with some modifications a la <Stuff>) should be added to the infobox, and I can do a bot run to remove the parameter from all recipe sheet pages. —Dr Ishmael 20:28, 12 July 2013 (UTC)

Oh, right.... we'll need to store the recipe_id in the infobox instead in order to drive the lookup. My spreadsheet shows there are 722 LearnedFromItem recipes. Oh joy. DUH! Just lookup the recipe sheet's name:

{{#ifeq:{{{type}}}|recipe sheet|
;[[Discipline]]s
:{{#vardefine:recipe-object|{{#ask:[[Learned from recipe sheet::{{PAGENAME}}]]|link=none}}}}
{{#show:{{#var:recipe-object}}|?Requires rating}} {{#arraymap:{{#show:{{#var:recipe-object}}|?Requires discipline|link=none}}|,|@@@|{{@@@}}| }}
}}

Example: Recipe: Candy Corn Custard — 50 —Dr Ishmael 20:41, 12 July 2013 (UTC)

Implemented, but needs a bot to remove the "level" parameters from pages in Category:Recipe sheets -Chieftain Alex 15:35, 13 July 2013 (UTC)

Vendor recipes

Currently it's not listed whether a recipe can only be unlocked through a recipe sheet obtained specifically by a (Heart/Karma) Merchant. Listing this would allow people to quickly find recipes which have to be purchased. For example, we could use the RDF capabilities of the wiki to quickly generate lists of all recipe sheets which have to be purchased, in general or sorted per discipline, crafting level, etc. I'm thinking this could be a simple boolean (1/0) parameter called "purchase", or a parameter with a specific set of potential values to offer more details. Opinions? ~ Sanna 21:32, 26 July 2013 (UTC)

Yes we do, it's tracked in the recipe template, not in the infobox. See Asuran Harpoon. With 2 exceptions, every recipe has a single source: if you can discover it, there's no recipe sheet for it; if there's a recipe sheet for it, it won't be unlocked automatically; etc. —Dr Ishmael 22:56, 26 July 2013 (UTC)

Ah, that looks a bit like it. I'll see if I can play around with that later. Thank you! ~ Sanna 14:27, 27 July 2013 (UTC)

Weapon skins

It would be somewhat useful for gallery template purposes to be able to annotate weapon skins in the infobox into a semantic property for "which type of weapon can I apply this skin to" (I think relyk (gz 21) brought this up somewhere previously, but I can't find it) Something like "Property:Applies to weapon type". The weapon infobox would fill this in based on the weapon type, but we might need another parameter for skin specialisation in this infobox. -Chieftain Alex 15:33, 10 July 2013 (UTC)

{{#switch: {{{skin type}}}
 | back item
 | head | shoulders | chest | hands | legs | feet
 | axe | dagger | mace | pistol | scepter | sword
 | focus | warhorn | torch | shield
 | greatsword | hammer | longbow | rifle | short bow | staff
 | spear | harpoon gun | trident = [[Has skin type::{{ucfirst:{{{skin type}}}}}]]
}}

Since back items also have skins available, perhaps "Property:Skin for item type" would be more descriptive. Clunky though. -Chieftain Alex 23:30, 10 July 2013 (UTC)

We only need to set Property:Has appearance and the appropriate category for the skins to generate the gallery if we use the current approach. I added the skin parameter to {{weapon set nav}} and categorization in the base template (we were doing that in all the anv templates anyways). We should have a parameter in the weapon/armor infobox for the equipment set and do the categorization there however. {{weapon set gallery}} doesn't need a mode because it's only pulling Has appearance, which is the same for equipment and skins, but we have to code to include both. I'd prefer we have a separate pair of templates ({{weapon skin nav}} and {{weapon skin gallery}}) because they use item infobox while weapon and armor sets use respective infoboxes, along with looking cleaner, etc.

{{#switch: {{{type}}}
 | back skin
 | back item skin = [[Is back item skin::Back item]]
 | armor skin  = [[Is armor skin::{{{skin}}}]]
 | weapon skin  = [[Is weapon skin::{{{skin}}}]]
}}

For the property in the item infobox, we need three separate properties to identify the type of skin, then the equipment type for the skin. Corresponds to Has weapon type, Has armor type, has trinket type (back item only). If we did [[Property:Is equipment skin]] (Skin for item type), we wouldn't be able to differ between weapon, armor, and back item skins in the queries.--Relyk ~ talk < 00:21, 11 July 2013 (UTC)

A single property would be manageable, because you can query for disjunctions of values: [[Has skin type::Helm||Shoulders||Coat||Gloves||Leggings||Boots]].

Side note: "Is" should only be used to begin property names if the property is a boolean. —Dr Ishmael 00:45, 11 July 2013 (UTC)

I wanted to avoid disjunctions, but it isn't that bad... >.>--Relyk ~ talk < 02:52, 11 July 2013 (UTC)

Actually, I just noticed that skins are split between armor skin and weapon skin categories, so there's no need for the property disjunction at all. Only one problem: back items are not armor, so back item skins need to get their own category. —Dr Ishmael 14:35, 13 July 2013 (UTC)

(Reset indent) Ok well I've implemented Property:Has skin type for both {{Item infobox}} and {{Weapon infobox}}.
After manually editing all those pages (with the help of Poke) to add the skin type parameter, I've also split Back items into their own category, Category:Back item skins.

I came across something that I didn't expect. Initially I had the property setup as a page type, but that didn't work cos it was redirecting "shoulders" to "equipment" - and I was using #set just fine for type:page, so I changed that to string/text to avoid it redirecting - and then I found that I couldn't use #set to write the property value (i.e. {{#set: Has skin type = Hammer }}), I had to use [[Has skin type::Hammer]]. Why is that? -Chieftain Alex 15:42, 13 July 2013 (UTC)

Whitespace - since the property type is text, SMW treats whitespace special, instead of trimming it. Try it without any internal whitespace - just uncomment {{#set:Has skin type=Hammer}} and preview, it sets correctly. —Dr Ishmael 15:57, 13 July 2013 (UTC)

^Make it a practice remove all whitespace in the #set function. I've messed it up before as well.--Relyk ~ talk < 19:56, 21 July 2013 (UTC)

Drunkard values

Why do values entered in | alcohol = show as links in the infobox? Ex: Stein of Golden Ale. Does anyone know how to fix this? -Somohexual (talk) 15:42, 10 September 2013 (UTC)

the property "Has alcohol content" hadn't been setup yet. Semantic properties default to being of type "page" - which automatically creates a wikilink. (smw:Help:Type Page) I've set it to be type number so it won't link anymore :) -Chieftain Alex 16:08, 10 September 2013 (UTC)

Thank you! :D I tried reading through smw:Help:User-defined_properties (thank you for the link) but I'm still pretty lost. If you don't mind, could you tell me how I can add more items to Property:Has alcohol content? Sorry, things like semantics and formatting aren't really strengths of mine. D: -Somohexual (talk) 20:36, 10 September 2013 (UTC)

It gets set by the infobox template. So just add the alcohol parameter to the infoboxes and it'll be set for you. —Dr Ishmael 20:56, 10 September 2013 (UTC)

OK, okay. Thanks. <3 -Somohexual (talk) 19:12, 11 September 2013 (UTC)

Skin sets

Can we get an optional parameter to add a skin set link? Nearly all skins are part of a set, so having this parameter would be useful for navigation. Psycho Robot (talk) 21:14, 28 November 2013 (UTC)