Template talk:Item infobox

From Guild Wars 2 Wiki
Jump to: navigation, search

Vista-file-manager.png
Archive



Miniatures[edit]

Would it be reasonable to add a parameter to denote whether a miniature works underwater? Currently, we maintain that data poorly. It's not always documented on the mini's page, especially when it doesn't work u/w and miniature only covers the specials...and I'm not sure whether that's updated as new minis are introduced.

What I'd like to be able to do is maintain the data on each mini's article and then use an appropriate query to populate the relevant table(s) on the generic page. Perhaps mini aquatic with parms of yes, no, and (by default) tbd, accounting for the ones for which we haven't documented whether it's been tested yet. As new minis are added (I smell Set 4 coming up), it's easy to add the articles and automatically update miniature. Plus, it will also remind people that some do work underwater and some don't.

At least, I think it's worth noting, because it's annoying realizing I'm missing a mini after "stepping" briefly into a lake (you know, when the special physics of Tyria decides that Newton's law should be expressed as "for each minor action when crossing from land to water, there is an unequal and more powerful reaction" and you end up 12 feet under). In particular, my decision to get the Mini Chickenado was influenced by whether it swims (alas, it doesn't).

On the other hand, this template is getting complicated and so perhaps there's an alternative method to maintain the data. – Tennessee Ernie Ford (TEF) 02:16, 23 July 2014 (UTC)

Multiple rarities[edit]

Each champion loot bag may drop in all rarities excepting ascended and legendary, but the rarity parameter does not allow multiple values. If the parameter is left empty, then chat link search will stop working. And multiple pages for rarities would be insane, as there's countless versions of each one. Any way around that? MithUser MithranArkanere Star.pngTalk 23:17, 14 September 2014 (UTC)

Leave both rarity and id blank in the infobox and use {{item variant table row}}. —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:09, 15 September 2014 (UTC)

Collection information[edit]

I think it would be nice to link if a item is part of a collection in the infobox. As this is a widespread change I will attempt to discuss this first before adding it. Anzenketh (talk) 18:31, 15 September 2014 (UTC)

I think that's a good idea. We'd have to add it to the various type-specific infoboxes, including weapon/armor/trinket/back item/... any others?
In terms of integration, I'm thinking we'll set Property:Is part of collection and then query that to build the lists on the collection page. Example: Shattered Lockpick would be [[Is part of collection::Trash Collector]]; then on Trash Collector we query {{#ask:[[Is part of collection::Trash Collector]]}} to get the list of all items in the collection. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:28, 15 September 2014 (UTC)
like collection = ...? -Chieftain AlexUser Chieftain Alex sig.png 19:52, 15 September 2014 (UTC)
For the input parameter to the infobox, yes, exactly. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:59, 15 September 2014 (UTC)

Nourishment effect ID[edit]

Are there any consumables that share the same exact effects? If not then we could add a second ID parameter for nourishment effects, so using the /wiki command with the effect brings you to the consumable directly as it already includes the icon and description of the effect, and we'll save making individual pages for those effects so they get shown in chat link searches (e.g: Player linking another player's effect to see what consumable gives that). In case there's consumables that share effects, would it be possible to make it so multiple pages appear in search? There's lots and lots of consumable effects. Linking directly to the consumable would save a lot of time of making effect pages. MithUser MithranArkanere Star.pngTalk 18:34, 21 October 2014 (UTC)

The API doesn't return a skill ID for nourishment effects (like it does for sigil effects or "special" equipment bonuses), so I can only compare the effect descriptions.
  • All "Extended" potions have the same effect as the "Powerful" version, but with a 2 h duration instead of 1 h. Since the duration is a distinct field, it seems like these would still have the same ID.
  • There are 8 different items with the effect +20 Power<br>+10% Experience from Kills
Item Duration
Rice Ball.png Rice Ball 10 m
Seared Beef Steak.png Grilled Steak 15 m
Roasted Meaty Sandwich.png Roasted Meaty Sandwich 30 m
Spicy Flank Steak.png Spicy Flank Steak 30 m
Bowl of Fancy Creamy Mushroom Soup.png Bowl of Watery Mushroom Soup 60 m
Eda's Apple Pie.png Eda's Apple Pie 60 m
Poached Egg.png Drottot's Poached Egg 60 m
Warden Ration.png Warden Ration 60 m
There are numerous examples in between, with a total of 173 items sharing 67 effects out of 382 unique effects. And that doesn't even count Feasts, because they don't have an effect description (they create an interactive object rather than directly bestowing the effect). Also, because the API doesn't give the IDs, it would be difficult to document in the first place. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:16, 21 October 2014 (UTC)

Collections now have hints.[edit]

A lot of collections now have hints. Would the item infobox be the best part to put this as the hint is usually how to obtain said item? This is different then description as description is value only as collection. Anzenketh (talk) 21:15, 3 November 2015 (UTC)

The hint is not a property of the item, it is a property of the item's entry in the collection. The hints should appear on the achievement/collection page (verbatim), but the item's page should have a complete description of how to obtain it (i.e. not a hint). —Dr Ishmael User Dr ishmael Diablo the chicken.png 21:45, 3 November 2015 (UTC)
(Edit conflict) Some (short) previous discussions on the topic here and here.
As I mentioned in the discussions above, the item's descriptions on the wiki should reflect what is in the game. Nothing less, nothing more. However, it clearly is an issue when they're included on collection pages, most notably the various legendary collections that have multiple steps which can be rather confusing without a guide. All of those pages use SMW to easily pull the information from the existing pages, which worked in the past because all of the collection items had descriptions that either hinted at the acquisition method or had a flat out description on how and where to get it.
Now, there could be several solutions here, which would both honor the existing formatting, and the way the information is presented:
  1. Change the item's generic description ("This item only has value as part of a collection.") to the hint shown in the achievement panel.
  2. Add the {{flavor}} template under the generic description for all of the hints shown.
  3. Use {{STDT}} tables, as seen on this collection page.
  4. Tinker the item infobox to allow both hints and the item description to stay, without one obstructing the other.
In terms of personal taste, the third option fits best, as it allows users to add additional information that might not be shown in the in-game hint. I'm not sure if the fourth option is possible or not, but it might be the best objective option out of the bunch. —Ventriloquist 21:46, 3 November 2015 (UTC)
I support option 3, it fits well with my argument above. —Dr Ishmael User Dr ishmael Diablo the chicken.png 21:51, 3 November 2015 (UTC)
I was thinking a variant of 3. It is also a good idea to make sure that people are aware on the item page that something is used in a collection that way they don't get rid of something that might be useful for them. If I am not mistaken all collections are collections of items. This is different from the achievement like Lion's Arch Exterminator while simular to a collection is not strictly one. I was thinking maybe we could use a template and SMW. Have the collection page list Item, description, and Hint. The description could be pulled via SMW and Item would be what it typed in with something simular to the way we type in rows in {{vendor table row}}. We can then use SMW to pull if is part of a collection and put that information wherever. Comments, concerns? On a side note I agree that a hint is not a item property but neither is it being part of a collection. Anzenketh (talk) 22:14, 3 November 2015 (UTC)
But why do you need the item description if the hint is more useful? Omit the description, skip any templates, and just write a table with columns "Item" and "Hint." —Dr Ishmael User Dr ishmael Diablo the chicken.png 22:32, 3 November 2015 (UTC)
You don't need the description if the hint is more useful. The purpose of the template(with SMW) has more to do with updating the item page that the item is used in a collection then updating the collection. Anzenketh (talk) 22:42, 3 November 2015 (UTC)
There's already a parameter in this infobox for that. —Dr Ishmael User Dr ishmael Diablo the chicken.png 22:46, 3 November 2015 (UTC)
Yes I was thinking of updating that "parameter" from the collections page instead of from the infobox page. A item being part of a collection is a property of a collection. Not a property of the item. Anzenketh (talk) 23:00, 3 November 2015 (UTC)
Interesting thing. In game the description "This item only has value as part of a collection" from what I have seen does not appear in game. Also There are some items that appear in multiple collections due to this we can't reuse the description field either. If we decide to just go with simply option 3 no more no less then what is the point of the "Is part of collection" property. I also don't think putting it into directly in the infobox is the best place due to some items can be part of many collections like Auric Sharpening Stone making the infobox rather ugly.Anzenketh (talk) 15:21, 5 November 2015 (UTC)
I altered Template:Default item parameter to remove "(achievement)" from the displayed text, which makes that page look less messy. —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:47, 5 November 2015 (UTC)

Recent changes[edit]

...have added whitespace underneath descriptions. Need a brave warrior to shoo it away. —Ventriloquist 22:53, 11 November 2015 (UTC)

Fixed by removing the display of {hint} and just setting the property. I'd like to know why the hint needs to be documented with the item anyway, when the only place it appears is on the collection. What's the point in setting the value here, then querying it on the collection page? Why not just put it on the collection page directly? —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:42, 12 November 2015 (UTC)
I don't know, and I'm still against having hints on the page. It's just a repetition of the acquisition section, especially when the hint is "talk to X to buy Y". —Ventriloquist 09:58, 12 November 2015 (UTC)
The only reason I saw to have it listed here, is simply because the hint text exists in game. As far as I was concerned, the hint wasn't being documented here because it was helpful and it was needed to locate the item, but because it was text on the item description (the collection "version" anyway), just like in-game description and flavor text. I didn't know a better place to document it. I'm fine with removing it from displaying, as long as we keep the property so it can be queried elsewhere. ~Mervil User Mervil Sig.png 09:54, 13 November 2015 (UTC)
Oh, in regards to putting it on the collection page. I felt it would be easier to have the hint text set as a property here so that it would be associated directly with the item, and so that it could be queried along with other properties of the item. I'm making a template that hopefully can be used on collection pages that queries for items that belong to a collection and displays them in a list, so that the long lists don't have to be hard-coded individually on the collection pages, when all the data already exists on the wiki, and so that they will all have uniform appearance. Example of my template in use. ~Mervil User Mervil Sig.png 10:17, 13 November 2015 (UTC)
Right, but... why does it need to be a property at all? Just hard-code it on the collection page, since that's the only place it needs to exist. —Dr Ishmael User Dr ishmael Diablo the chicken.png 15:46, 13 November 2015 (UTC)
Well, again, my thoughts are this. Some items' only in-game description IS the hint (Dierdre's Perspective, Tribute to Ancient Haivoissen). This hint text is displayed on this wiki as the item's "description", but it is clearly hint text. I feel we either display the hint text, or we don't. If we collectively decide to not display the hint text, then we need to decide how to handle the trophy items that don't have anything but hint text. My preference would be to just display the hint text in the in-game description, or somewhere on the page under a heading such as "Collection", say "As part of a collection, this item has collection hint text: "Talk to Dierdre in the Hidden Garden jumping puzzle upon its completion." ~Mervil User Mervil Sig.png 20:37, 13 November 2015 (UTC)
There's nothing wrong with items without descriptions. I usually add a basic intro sentence (e.g. Tequatl's Eye) while mentioning other relevant info in the other sections. Hints do not offer anything to the page that cannot be mentioned in the acquisition or the notes section. —Ventriloquist 20:46, 13 November 2015 (UTC)
Exactly. Instead of the (usually) vague hint, we'll have an Acquisition section that tells you exactly how to get the item. The hint is redundant and useless in that case, and since it's very clearly not part of the item's actual description, there's no need to display the hint anywhere on the item's page. —Dr Ishmael User Dr ishmael Diablo the chicken.png 22:14, 13 November 2015 (UTC)
So Dr. Ishmael. What recommendations do you have for being able to query for Is part of collection, generate a list of those items, and hard-coding the hint text so it appears only there rather than the item's page? I'm trying to find a solution for this hint thing without putting "unnecessary" information on the item's page. What about like what Ventriloquist suggested (and I suggested above him)--putting the hint text in the notes section or acquisition section, that way the text is there and can be set as a property to be queried by my template? ~Mervil User Mervil Sig.png 06:20, 14 November 2015 (UTC)
You might be getting ahead of yourself on the semantic properties. We haven't decided on formatting the collection articles. If you want to technically implement it, we would do {{collection item|<item>|<hint>}} in a list on the achievement subobject template. Even then, I don't think we'd semanticize it because any way we store the information is terrible the way we have it, the hint text isn't useful, the text is relatively static, and we won't be using the hint text in any queries. I'd say the best approach is to treat the hint text as trivial information and list it manually on the achievement pages in its own section after major sections.--Relyk ~ talk < 06:57, 14 November 2015 (UTC)

(Reset indent) If you are looking at the hint text as a hint that is unhelpful for locating an item, sure, it's trivial. However, how ever unhelpful you feel the hint actually is, it is still text and a property of the collection item. I don't find the flavor text or in-game description very helpful for locating the item either, or its icon. I cannot locate the item in-game by looking at its icon, no matter how long I stare at it. However, be that as it may, it has been documented on this wiki. What for? does it serve a purpose? Does documenting the in-game description actually serve a purpose? No, it doesn't. It too is trivial, and only listed on the item's page (and nowhere else). But, it is listed, probably for sake of completeness, and stored in a property. It is a part of the item. People are documenting these things on the wiki. The hints are being recorded. They are here. What are we going to do with them? I don't know how to hard-code the hint text onto the collection items' pages without hard-coding everything else related to the item including the item name, icon, description, etc. I feel that if the data is already stored on the wiki (via infoboxes), why re-type everything out? It just seems logical to make a template that can gather the data and then display it, much like the [[Template:Achievement|achievement template]]. The ONLY thing missing for these templates to show all the collection item information, is the hint text. Will the hint text be listed anywhere else? Probably not (but neither is the item's description). But it would make pulling data onto a page with a template so much easier if it was stored in a property. ~Mervil User Mervil Sig.png 07:24, 14 November 2015 (UTC)

We document the icon and the flavor text because they are clearly part of the item as they appear directly in the item's tooltip when you have the item in your inventory. The hint only appears on the tooltip in the collection screen, so it's NOT part of the item - the only thing it's associated with is the collection.
"I don't know how to hard-code the hint text onto the collection items' pages without hard-coding everything else related to the item " You do it exactly like Relyk suggested, by having a template {{collection item|<item>|<hint>}} where you hard-code the item name and hint text as inputs, then it queries the item's icon and displays the icon, name, and hint in a table row. We can even invert the current Property:Is part of collection that points item→collection and have this new template set a new property (name TBD) that points collection→item, then set up this infobox to query for which collections the item belongs to. —Dr Ishmael User Dr ishmael Diablo the chicken.png 15:59, 14 November 2015 (UTC)
Building a table one row at a time was one option I considered, and the only way to hard-code the hint text onto the page and draw in already coded item properties, but I was trying to avoid doing each item individually, but rather to query all items "propertied" as belonging to a specific collection, and then draw them into a table.
Anyway, what do you guys think would be the best way to accomplish what Relyk and Dr. Ishmael suggested? #1) Build the tables one row at a time with a {{collection item}} template on the collection page, #2) code in a series of {{collection item}} templates into the achievement table row template that assigns each collection item to the achievement, but also sets the hint into a Has collection hint property, or #3) put the template onto each items individual page, and sets the hint into a Has collection hint property? (the latter wouldn't necessarily have to display the hint on the page, just set it). ~Mervil User Mervil Sig.png 17:31, 14 November 2015 (UTC)
I don't want to do any of that. We need to decide on how we format collection achievement pages first. Semanticizing content comes later.--Relyk ~ talk < 17:40, 14 November 2015 (UTC)
There is absolutely no reason to annotate the hint at all. It only needs to appear in one place - on the collection page. The only reasons for annotating something are a) so that it can be used as a semantic query condition or b) so it can be displayed on other pages by returning the property from a semantic query. These hints obviously can't be used for a), and since there's only one place they need to be shown, they don't qualify under b) either. —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:13, 14 November 2015 (UTC)
Playing devil's advocate here... Was there a reason to annotate the item's description? It gets displayed by the infobox, but by so doing, gets stored into a property. The in-game description is never used for a query, and only appears on the item's page. The in-game description doesn't meet either of your reasons above, but it gets "propertied" anyway. In regards to the hint text, perhaps it does qualify for your b) reason above. For example: we added a Has collection hint property and a {{#set: function to the item infobox template. Currently, I think the only item that utilizes this hint property is Destroyer Jar. It's not displayed anywhere on the page, but is used to populate a template I've been working on. Just to show it's use, I updated the Frostfang_I: The Experimental Axe to utilize this template. Please take a look. the appearance of the table generated can be changed of course, but the benefit of this template is that now, lay editors can just plop the template onto the collection pages and a list is generated. However, the hint text isn't included unless there is a hint property set for the item. It may not be ideal, but it works well. ~Mervil User Mervil Sig.png 19:59, 14 November 2015 (UTC)
What part of "it only needs to be shown in ONE place" is difficult to understand? Annotating it on one page where it's not displayed, then querying for it and displaying it on one single other page is inefficient and pointless. —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:57, 15 November 2015 (UTC)
You point out "inefficiency". You see, I think its more efficient to type this:
{{collection list}}
than this:
{{collection item|item A|Hint=Hint: do this to get item A}}
{{collection item|item B|Hint=Hint: do this to get item B}}
{{collection item|item C|Hint=Hint: do this to get item C}}
{{collection item|item D|Hint=Hint: do this to get item D}}
{{collection item|item E|Hint=Hint: do this to get item E}}
{{collection item|item F|Hint=Hint: do this to get item F}}
{{collection item|item G|Hint=Hint: do this to get item G}}
{{collection item|item H|Hint=Hint: do this to get item H}}
{{collection item|item I|Hint=Hint: do this to get item I}}
{{collection item|item J|Hint=Hint: do this to get item J}}
etc. for 15-31 entries. And if you are referring to inefficient use of the wiki server by storing the value in a property...what's the difference? It's already being done all over the place (again, I am referring to properties such as the in-game item description that continues to NOT meet either of your 2 reasons above for being semanticized. And yet, there it is, using up wiki server space. At least with hint text, theres a purpose behind it...efficency ~Mervil User Mervil Sig.png 03:46, 15 November 2015 (UTC)
Has nothing to do with server space. {{collection list}} implies a query template, which means storing the hint text across 15-31 articles and using a query to format the result, which needs to be formatted correctly. It also means you now have a page with more queries, with all the baggage that comes with semantic queries. That all takes resources for the wiki and editors.--Relyk ~ talk < 05:10, 15 November 2015 (UTC)
Well, OK then. But I thought the whole purpose of semantic wiki was to make such queries. My understanding was that it made overall less baggage, and less repetition. Whole pages can be created with templates that can be accessed over-and-over, without creating and storing each individual page. I was not under the impression it was inefficient with lots of baggage. Admittedly, I am no expert here. I defer to you guys in what's efficient vs inefficient when it comes to back-end stuff. In any case, I think the consensus is to not have hint text on item pages. It seems appropriate to keep it localized to the collection pages. So, where and when do we start the discussions on format of the collection pages? ~Mervil User Mervil Sig.png 05:22, 15 November 2015 (UTC)
What makes more sense: 1) storing a bit of text on the only page where it is displayed, or 2) storing a bit of text on a page where it's not displayed, then displaying it somewhere else? Seems like an easy answer... so why did we waste all this time arguing about it? —Dr Ishmael User Dr ishmael Diablo the chicken.png 05:52, 15 November 2015 (UTC)

(Reset indent) I'll be honest, it wasn't that simple in my mind (kind of still isn't). To me, the simplicity increases by putting the hint text on the item page, so a single template can call all of it. It seems like more work to create a collection table row by row. In either case, a bit of text is being stored. But in one method, you have to type a bit of text out on every row along with at least one existing property to call a template on every row, or you type a bit of text on every infobox, and use a single template to pull it all together. Lastly, you were making arguments against adding properties, but they weren't holding water because precedent had already been set--properties have been made and stored (ie: in-game description and flavor text) that are not being used. I guess it depends on what part of all of this you focus on. Which is more important: simplicity in where the text actually is, or simplicity in how the text gets there. FYI: my statements here are ONLY to answer your question about why there was an argument, and not to further the debate. ~Mervil User Mervil Sig.png 06:15, 15 November 2015 (UTC)

Simplicity was never the issue in the first place. And I'll be honest, I'm not sure what you're getting at because you are using simplicity in multiple contexts. The single template design you are referring to is a parameterized query template and the reason for designing it that way is because of its elegant and ease of use. The template itself is quite complicated. We could wrap the series of row template calls in a single template, but that doesn't make the design any simpler.--Relyk ~ talk < 07:06, 15 November 2015 (UTC)
Just to throw in my 2 cents here... Being an object-oriented programmer, I can't help but think of modularity. According to the principles of modularity in object-oriented programming: we should have {{items}} that contain an id and description (for simplicities sake), then we would have {{collection item}}, which is a subclass of {{items}} that would contain id, description, and hint. This is true of database designs as well. An object should never contain more than what others need of it (you don't ever just create 1 big database table, you create many little tables). Therefore, I would have to agree that an item should not have a hint as a property of it. A {{collection item}} IS-A {{item}} with an extra property called hint.
Although, after saying all that, this isn't programming... this is a wiki. And I can't help but prefer that the hint be a property of an item. Hekela (talk) 04:08, 16 November 2015 (UTC)

Moving forward[edit]

I've created Template:Collection table row as the first step in getting this moving. I converted Astralaria I: The Device to use it, as proof of concept, and then edited Ponder the World to show how the item pages should be structured. In this case it was as simple as rephrasing the hint and making it obvious that "Ponder" is referring to the /ponder emote, something that people who've never played Mad King Says may not realize. I'm sure that in many other cases, the acquisition won't be so simple, making even more of a distinction between that and the hint.

The next step will be to remove the {collection} parameter from this infobox and decide how we want to use [[Property:Collects item]] (WIP name), which is set by the collection row template, to dynamically generate the list instead. I'm thinking that we may not want this collection list in the infobox anymore - some items, like Auric Sharpening Stone, are a part of many collections, and it tends to bloat the infobox. On the other hand, most items only belong to a single collection, making the ASS (unfortunate acronym...) an outlier.

Also, if the query is in the infobox, it would have to run on every single item page on the wiki, including the thousands of items that aren't part of any collection. On the other hand, the infobox already has a query to find the crafting disciplines that can use an item, so maybe it wouldn't be that bad.

In any case, it would be possible to create an analog of Template:Contained in that we can put in the article itself only on the pages that need it. I'm not sure which way is better - baked into the infobox or standalone template in article. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:45, 17 November 2015 (UTC)

Should we even keep the term "hint" in the table if it's explicitly listing the acquisition method? Hints are ambiguous, whereas our information is pretty clear.
How would the collection items display their collections, if we remove them from the infobox? Often times editors will (unnecessarily) add the collection to the notes section, unaware it's already listed in the infobox. Would this remedy that problem or cause more issues?
However, I'm all for making the infobox a tidier place - especially when you have items with nine collections...Ventriloquist 21:25, 17 November 2015 (UTC)
I think you might be confused? The collection table has the hint; the item's page has an explicit acquisition. I'd be fine leaving the hints off of the wiki completely, but it seems like a lot of people think the hint is important enough that we need to display somewhere, thus the long argument above about where to put it.
If we put the collection on the page, that would almost certainly stop people adding it to the Notes, I'd think. —Dr Ishmael User Dr ishmael Diablo the chicken.png 22:06, 17 November 2015 (UTC)
Oh, the hints in the tab in your example confused me, didn't realize they were actual in-game hints. Other than that, the idea sounds good. —Ventriloquist 00:32, 18 November 2015 (UTC)
The way we did achievements wasn't designed for appending achievement properties to the achievement page. You need two queries, one for the achievement subobject and one for the collection list. Doing queries will also suck because you have to remember the collection items aren't located in the subobject and have to query if there's an achievement page defined every time. Given I don't see us doing much beyond listing the vendor cost, Alex will probably write some spaghetti code once someone asks. I'd still prefer storing in the subobject or finally creating a page for every achievement.--Relyk ~ talk < 05:14, 18 November 2015 (UTC)
Good start. Two thoughts. 1) the collection table row template gives the item name and hint, but what about the "in-game description"? Many (most) of the collection items don't just have hint text, but also some other in-game description. Please see Frostfang I: The Experimental Axe to see a collection table with each item's description and hint text for an example of what I mean. 2) Ponder the World is an interesting item, because it's one of the several "items" for these precursor collections that doesn't actually have an existing in-game item, and the only text on this "item" is the hint text. I believe the consensus above was to NOT display the hint text on the item pages. I would prefer to be consistent. Either we display the hint text on all the collection items, or not.
Oh, another thought. Rising Stars is a "collection item" for Astralia I, however, this "item" is not an item at all, but simply requires you to interact with an in-game world object (different from items such as Ponder the World, because Rising Stars existed in-game before these collections were released, and therefore already has a page). That page doesn't use the item_infobox. Do we handle these differently, or just leave em alone? Should we create a different page for [[Rising Stars (collection item)]]? ~Mervil User Mervil Sig.png 09:55, 18 November 2015 (UTC)
@Relyk: Bah... I give up, let's just make all collection stuff static.
@Mervil: Is it really useful to have it on the collection page? I think it's just more clutter, the same way that putting the hint on the item page is clutter. As for that Frostfang I table specifically, it's crap. Rowspans are crap - the entire point of a table is to have one row per "thing", and rowspans completely screw that up. Making the hint text a pale color just to match the in-game color is crap because it makes it hard to read, especially when the hints are all mashed up with the descriptions, which are black and easy to read. The hint is the more important bit of text there, so why make it harder to read than the non-important text?
@Mervil 2: If we can't get an item ID, then I say they're not items. Of course, that means someone will have to go and delete a crap-ton of pages that people have already created for these pseudo-items. —Dr Ishmael User Dr ishmael Diablo the chicken.png 14:56, 18 November 2015 (UTC)

(Reset indent)

My thoughts:
  • Achievement pages:
    • Collection stuff should be static ingame (they generally don't get added to) so the achievement pages should be safe enough to have as static tables. We can enter the hints manually here
    • Hints should appear in black.
    • Descriptions aren't needed on collection pages. Fluff.
  • Item pages:
    • Hints don't appear on items = they shouldn't be in the item infobox.
    • I don't see a problem with putting an acquisition section on each item page which may or may not be an exact transcription from the ingame hint (preferably our description should be better than ingame, otherwise what is the point in checking the wiki).
    • I like having a collection parameter in the item infobox, there aren't many items appearing in multiple collections.
  • Collection "items" which aren't items:
    • These probably shouldn't be pages if we can't get IDs.
    • Accordingly I've updated {{collection table row}} to check for the page existing before using item icon - this should prevent people from reaching a page that shouldn't exist..
-Chieftain AlexUser Chieftain Alex sig.png 16:07, 18 November 2015 (UTC)
What about flavor text? We changed the color of flavor text to match in-game.
Are you suggesting that the pages for "items" such as Ponder the World should be removed all together? or just changed from item type? Just because they're not actual items doesn't mean they shouldn't have pages. They are after all still part of the collection. You can't have pages for 18 of the collection pieces and not have pages for the other 2. I think we should just keep them the way they are. We still need to figure out what to do with pages such as Rising Stars.~Mervil User Mervil Sig.png 18:48, 18 November 2015 (UTC)
Agreed, they should still be pages, absolutely. Just because they aren't items, doesn't mean they aren't in-game content. Side note, I greatly dislike flavour text; drives me nuts. Hekela (talk) 18:51, 18 November 2015 (UTC)
(Edit conflict) Flavor text color is still bright enough, and it's always against a plain white background, which means it's still readable. In your table, the background row-color and the borders make the hint coloring even less readable. To be blunt, your table is very poorly designed. —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:57, 18 November 2015 (UTC)
Geeze. The table was not final. I had planned to continue making it better, but I scrapped the project after the discussion above. But thanks for your...critique. ~Mervil User Mervil Sig.png 19:15, 18 November 2015 (UTC)
For things that are part of collections but aren't items, maybe we can have a {{collection task}} or something to that effect? That way it's clear, it's not an item, but it is part of a collection. Hekela (talk) 19:25, 18 November 2015 (UTC)
Don't mind ishmael, he can get grumpy sometimes. "You can't have pages for 18 of the collection pieces and not have pages for the other 2." We definitely can. After all, that's exactly what we're doing with achievements. Just don't add a wikilink.
For pseudo-items like Ponder the World, there isn't a point in having pages. It's the same reason we don't create pages for the personal story items (I hope). The pages are just pretty much a description of what the pseudo-item is related to or acquistion. The item properties is superfluous information users don't care about.--Relyk ~ talk < 22:51, 19 November 2015 (UTC)
While I know quite a bit about how various things in the game actually work (e.g. there's no distinction between effects and skills, they're all contained in a single enumeration), I don't know anything about how collection achievements work. However, it seems very likely that the collection entries are a distinct type of "game thing" from everything else - they already cover two pre-existing "thing" types, items and skins. Thus, if they are indeed their own thing, then Relyk is right that we shouldn't treat them as if they were something else (i.e. items). —Dr Ishmael User Dr ishmael Diablo the chicken.png 02:19, 20 November 2015 (UTC)
Against creating not-really-items as well. The only thing I'm sad about is the icons they use. Could we integrate those into the table, without creating an item page? If we're going to be listing them, might as well, right? —Ventriloquist 15:57, 20 November 2015 (UTC)
Yes, just put the icon and name like normal. We don't have a generic icon template thanks to lolwiki, so we'd use {{icon}}.--Relyk ~ talk < 03:42, 21 November 2015 (UTC)
Just hard-code the file link. We don't have to use templates for everything. :P —Dr Ishmael User Dr ishmael Diablo the chicken.png 03:54, 21 November 2015 (UTC)

Tooltip structure: Automate "Double-click to consume", yes?[edit]

With the addition of Anguished Tear of Alba, a nourishment consumable with a non-blank description, the structure of tooltip is more "transparent" – transparent enough to recreate it via code. "Double-click to consume.\n" isn't actually part of the description that can be extracted via the API (see https://api.guildwars2.com/v2/items/70596).

  1. Should we automate the addition of "Double-click to consume.\n" (found on all "consumables" on the wiki) via the infobox?
  2. If we're not doing automatic inclusion of such text to replicate the in-game tooltip, how do we format Anguished Tear of Alba using {{{description}}} and {{{variables}}} when the nourishment text appears in between "Double-click to consume." and "Grants 10 agony resistance. Does not stack with other sources of agony resistance."?

The case where automation is not useful is probably Black Lion Trading Contract (tooltip looked like http://i.imgur.com/dDAJC.jpg), although I'm wondering what a more current tooltip would have looked like if anyone still has access to this historical item. --BryghtShadow (talk) 13:06, 12 November 2015 (UTC)

Another consumable that I overlooked with a similar structure is Experimental Mordrem Extraction Device (https://api.guildwars2.com/v2/items/67818). --BryghtShadow (talk) 14:20, 12 November 2015 (UTC)
I've always felt that it's pointless to include the "Double-click to consume" since, as you discovered, it's an automated part of the in-game tooltip rather than part of the item's actual description. It's also redundant when the item's type is already listed as "consumable." —Dr Ishmael User Dr ishmael Diablo the chicken.png 15:51, 12 November 2015 (UTC)
If we're excluding that blurb, then that makes formatting the consumables easier: {{{variables}}} (nourishment, etc) before {{{description}}}. --BryghtShadow (talk) 19:28, 12 November 2015 (UTC)
If we did it correctly, we would have specific parameters for gemstones and nourishment instead of {{{variables}}} so we don't have ambiguous formatting.--Relyk ~ talk < 12:54, 13 November 2015 (UTC)

Support for Consumable subtype: Service or Immediate[edit]

Could we add support for the type "Service" or "Immediate"? The API contains Immediate consumables, which have the localized tooltip type "Service" and have the blurb Takes effect immediately upon receipt.<br> before the actual description. Aetherium Production Boost (1,000 Influence) for example is "description":"Converts 1,000 influence to 10 minutes of boosted aetherium production." --BryghtShadow (talk) 05:06, 29 December 2015 (UTC)

Decoration processing time[edit]

When the item is a decoration, the processing (i.e. cooking) time after crafting it would be a useful stat to list. This varies by item. -- Dashface User Dashface.png 08:57, 2 January 2016 (UTC)

Yeah, I already posted a simular question at User talk:Dr ishmael#Separate_infobox.3F. —MatHack (talk) 23:20, 2 January 2016 (UTC)
No need for a new infobox imo, but I don't know if these belong on Template:Recipe or on Template:Item infobox - I'm unfamiliar with scribing but the assembly time + resonance cost sounds like something better fitting in the recipe template. Schematic type is an item infobox thing I expect.
Not all parameters need to be semantically annotated either, i.e. where would you usefully display each bit of information in queries?
  • Property:Has schematic type - 1Yes okay
  • Property:Has assembly time - 0No meh
  • Property:Has resonance cost - 0No meh
By all means add these 3 parameters though, make them display at the top under the
Afterwards, if you want me to add the parameters to the pages with an editing bot, and you have all the data in a table, then I can do that. -Chieftain AlexUser Chieftain Alex sig.png 00:13, 6 January 2016 (UTC)

API fields[edit]

I need to add some entries to this infobox for the API stuff, but I need some second opinions on them (since editing this infobox rebuilds the entire wiki and I'd like to not have to do it more times than necessary).

Skin unlocks

Does this look reasonable for showing skin unlocks? I'd prefer to use "Skin unlocked" but there's not enough room for it without it wrapping. Note that the skin infobox (at Princess Wand (skin) in this case) already uses "Unlocked", but that's on an infobox dedicated to the skin, not to the item that unlocks the skin.

{{Armor infobox}}, {{Weapon infobox}} and {{Back item infobox}} have the same problem. Here's the armor infobox: https://i.imgur.com/7MKolRp.png. (Any other templates I missed?)

Mini unlocks

Same deal as skin unlocks, but this is more annoying because minis can also be items, so we also have a "You have" row for them: https://i.imgur.com/TTqGiDA.png. I'm ok with this personally, but maybe it's confusing if you don't realize the item/wardrobe split. The problem here is that the "You have" row is added by {{Default item parameter}} so we'd have to pass extra params in to modify or hide it, and also that the JS for "You have" will end up pretty messy if it needs to handle minis too.

Recipe unlocks

I plan to add this for recipes: <span class="api-unlockedon api hide" data-recipeid="{{#ask:[[Learned from recipe sheet::{{PAGENAME}}]]|?Has recipe id#=|mainlabel=-}}">…</span> which should work ok even when the sheet has different variations (Recipe: Gift of Blades) or teaches multiple recipes (Box of Recipes: Tooth of Frostfang).

-- Dagger (talk) 04:04, 8 January 2016 (UTC)

The infobox shouldn't be handling this in the first place. Like poke said in the discussion, the information needs to be visually separated and that should all be handled in separate templates. I also don't think people need the information on every page they visit and hence make unnecessary API calls. That's why a form would be appropriate, just like we do we base ingredients. A similar solution is to add a "personal" tab at the top.--Relyk ~ talk < 04:37, 8 January 2016 (UTC)
Yeah, I disagree. This stuff is useful because it's right there on the page. All the data is cached after requesting anyway, so it's not like there's that many API calls. -- Dagger (talk) 10:47, 8 January 2016 (UTC)
Forms aren't applicable for this purpose.
Miniatures. Pass a parameter to {{Default item parameter}} to allow you to not process the "you have" line if a value is set. Example: {{Default item parameter|hideapi={{#ifeq:{{lc:{{{type|}}}}}|miniature|true|false}} }} on item infobox, with {{#ifeq: {{{hideapi|}}} | true | | <span class="api-unlockedon api hide" ... </span> }} on Template:Default item parameter. whatever, show both.
Recipes. Fine, but {{pagename}} needs to be {{PAGENAME}}. (Corrected in your line given above)
Have you got a sandbox copy of the infoboxes that you're working on? (I have some other questions which I'll ask here. -Chieftain AlexUser Chieftain Alex sig.png 14:03, 8 January 2016 (UTC)
The number of API calls is probably the part I least care about.::@Dagger, I don't know what part you are disagreeing with. Being right on the page doesn't mean it is useful or that we put it in the infobox template.
@Alex, why not?
There's literally no discussion about why we should add account information to the item infobox or why that's the best way to do it. If that's all this discussion is going to be, I won't bother and you guys can do whatever you want.--Relyk ~ talk < 15:34, 8 January 2016 (UTC)
The entire point of Dagger's API additions are that you can check your ingame stuff vs the wiki stuff at a glance. Going to another page (which the user will probably have to follow a link to, or find themselves) isn't very user-friendly either. Also, I don't think you've checked dagger's js code, but afaik it queries the account API a maximum of once every 12 hours for each of the endpoints (5 endpoints, so 10 calls a day). -Chieftain AlexUser Chieftain Alex sig.png 15:53, 8 January 2016 (UTC)
That's pretty much it. The cache time is actually set to 5 minutes at the moment for development, but that's just a config knob. -- Dagger (talk) 16:00, 8 January 2016 (UTC)
The number of API calls is probably the part I least care about. "The entire point of Dagger's API additions are that you can check your ingame stuff vs the wiki stuff at a glance". What does that have to do with the item infobox? Why can't people go to a page that does just that?
I didn't say anything about going to another page either, the form/link can simply reload the item page with the account information. Going to another page is actually user-friendly though because the account information isn't confused with the rest of the information about the item itself. It's a way to separate the information and avoid using caching as a solution. That also doesn't explain to me why we need to put the account information in the infobox.--Relyk ~ talk < 11:25, 10 January 2016 (UTC)
I'm not sure if it has to be in the main infobox, but having the info somewhere on each page would be really handy, especially for skin and dye unlocks. It's a "don't worry, you already have this" indicator. -- Dashface User Dashface.png 15:56, 10 January 2016 (UTC)
This info is most useful when it's available, as Alex puts it, at a glance. That means it should be available directly on the item page, not hidden behind a link you have to manually invoke. And I put it in the infobox because that's where other info (like the TP price) goes.
I don't really see how there can be much confusion about where the info comes from. The fields stay hidden unless and until you set an API key. It should be fairly obvious that the info they show comes from using that key, especially if the page where you set the key explains what you'll get by setting one (which is obviously a thing it should do). -- Dagger (talk) 00:15, 11 January 2016 (UTC)
The problem with miniatures is that's also possible to have them as items too. But maybe it's okay to just hide the item counts anyway and ignore that?
I haven't made any sandbox copies. I tend to rely on DOM Inspector to make local mockups (and lots of time with the preview button to make sure the edits I make are sane). How do you normally make mockups of these things -- a full copy of the template, or just recreating the markup? Copying the template seems like it's going to leak SMW properties everywhere. -- Dagger (talk) 16:00, 8 January 2016 (UTC)
You could display miniatures in the inventory if you wanted to, I guess there is no harm in displaying it too...
I usually make a full copy of the template in my userspace, tinker with it (I'm a terrible editor so I make loads of mistakes), test it, then tag it for deletion when you're done with it. -Chieftain AlexUser Chieftain Alex sig.png 16:41, 8 January 2016 (UTC)

Alright, let's do it. I can always move them up in JS locally if it bugs me so much. -- Dagger (talk) 23:43, 27 January 2016 (UTC)

Hints Again[edit]

So above, I think we all agreed that (at the very least) item pages shouldn't display the hint (and some suggested that infoboxes shouldn't even have a hint property). However, not only do infoboxes have the hint property, but they are also being displayed. Can someone hide the hint, at the very least? Hekela (talk) 22:27, 3 June 2016 (UTC)

Should bound be specified for service items? Tooltip vs API[edit]

I've coded the service type to be tradeable=no by default, so that it doesn't look up TP prices. The API has flags like AccountBound which are never seen in the tooltip. Should bound be specified on the pages? e.g. https://api.guildwars2.com/v2/items/68565 = ["AccountBound","NoSalvage","NoSell","Unique","AccountBindOnUse"] --BryghtShadow (talk) 08:41, 13 September 2016 (UTC)

Schematics are trophies[edit]

Schematics are trophies. They are products of crafting, not ingredients. The recipes on the wiki with schematics as ingredients should be corrected to guild upgrades. e.g. https://api.guildwars2.com/v2/recipes/11563 --BryghtShadow (talk) 10:20, 15 September 2016 (UTC)

Some schematics are Crafting Materials. e.g. https://api.guildwars2.com/v2/items/70982. How should the trophy schematics be handled? --BryghtShadow (talk) 10:27, 15 September 2016 (UTC)
Trophy schematics:
  • Schematic: Airship Defense
  • Schematic: Armored Dolyaks
  • Schematic: Assault Roller
  • Schematic: Centaur Banner
  • Schematic: Chilling Fog
  • Schematic: Cloaking Waters
  • Schematic: Dragon Banner
  • Schematic: Emergency Waypoint
  • Schematic: Gate Turrets
  • Schematic: Hardened Gates
  • Schematic: Hardened Siege
  • Schematic: Invulnerable Dolyaks
  • Schematic: Invulnerable Fortifications
  • Schematic: Iron Guards
  • Schematic: Minor Supply Drop
  • Schematic: Packed Dolyaks
  • Schematic: Presence of the Keep
  • Schematic: Sabotage Depot
  • Schematic: Speedy Dolyaks
  • Schematic: Turtle Banner
  • Schematic: Watchtower
  • Vault Transport
Crafting Material schematics:
  • Guild Banquet Schematic
  • Guild Experience Banner Schematic
  • Guild Gathering and Swiftness Banner Schematic
  • Guild Gathering Boost Banner Schematic
  • Guild Gold and Magic Find Banner Schematic
  • Guild Gold Gain Banner Schematic
  • Guild Heroes Banner Schematic
  • Guild Karma and Experience Banner Schematic
  • Guild Karma Banner Schematic
  • Guild Magic Find Banner Schematic
  • Guild Road Marker Schematic
  • Guild World Event Schematic
--BryghtShadow (talk) 10:42, 15 September 2016 (UTC)

Preview[edit]

Should we have a 'preview' parameter to indicate if an container can be previewed? Now some containers have a preview, but there's a few more that contain skins that also have a preview with the skin even though the item itself is a container for a skin. MithUser MithranArkanere Star.pngTalk 15:35, 2 November 2016 (UTC)

Hmm, late on this but that sounds like a nice idea, not sure how it would work though. --Txon Atana - (talk) 02:38, 26 July 2017 (UTC)

Adding the API[edit]

Is there any particular reason why we shouldn't add/haven't added the link to the API for items like we do for skills & skins? Seems like it would be very handy thing to have here. - Doodleplex 04:49, 28 June 2017 (UTC)

Great idea Doodle, I look forward to you adding it!--Relyk ~ talk < 05:19, 28 June 2017 (UTC)

Changes to Storage tabs classification[edit]

Ok, after trying to edit an item I followed links and reached this template, I thought about updating stuff but then I saw it would cascade to a lot of changes around. Then, before I would mess something I'm bringing this up. How would the wiki reflect the changes to the new Storage tabs classification? As stated in patch notes: "The Common, Fine, and Rare Materials collections have been renamed to Basic, Intermediate, and Advanced, respectively.". The Crafting material article would be affected, with the sections being changed to reflect that change, however, if that article is changed this template can become broken.

Additionally, out of curiosity, what's the reason for having two "rarity" fields (one for the "item"(?) another for crafting material)? I just can't see how, let's say, an item showed as Rare in inventory would have a Fine material rarity. The fields "material type" and "material storage" seems redundant to me (unless it's used in some semantic though, the "material storage" field doesn't seem to generate any visible info in the infobox). --Txon Atana - (talk) 02:35, 26 July 2017 (UTC)

material type is due to the crafting infobox originally being separate from the item infobox. We identify a crafting material by type = crafting material and then provide information related to materials such as the actual type, crafting tier, crafting disciplines, and material storage categorization. The wiki crafting type is a misnomer because it may or may not match the canonical type, which tends to be a generic CraftingMaterial type.
The reason is we use the type parameter for wiki categorization, which provides much more granular and useful organization and categorization. We use the material storage categorization as the material type because it's an existing crafting type rather than a wiki-level type. Although that has some drawbacks since we don't, say, group all the ores together as a material type. We can probably pull out the material types into material storage to avoid redundancy, which would be much more work.
The changes affect the material storage categorization only, so it would be a 1-to-1 change for existing types. If we wanted to update it properly, we could pull out the material storage categorization completely from the material type i.e. set both parameters as the same and update the material type to whatever we want later.--Relyk ~ talk < 03:18, 26 July 2017 (UTC)
I got it, thanks. Yeah, since I didn't see any "Material Storage" entry in the generated infobox I guessed it would be used for some internal classification. Well, I don't know how it could be done or how much work would involve but I feel some areas like mainly the Crafting material article needs to reflect the change. But apparently changing only that article might break this template somehow, as it links to sections to that article. --Txon Atana - (talk) 03:30, 26 July 2017 (UTC)

Consumable Type[edit]

I’d like to discuss if it’s necessary to have a consumable type parameter instead of addition item types. If we compare the API item types to the parameters for this infobox we can see that many of the consumable variants have their own type already. Consumable: Booze is alcohol, Consumable: Food is just food , Consumable:Immediate is service. I think we need to decide on which style to keep to avoid labeling conflicts in the future. J.Tesla (talk) 14:50, 7 October 2017 (UTC)

I would say I think it a reasonable idea. If we could get it in sync with the API somehow it might be easier to classify stuff. However, I can't opine much since I'm not much familiar with the ways the API shows info, but more and distinct info in the wiki sounds good. --Txon Atana - (talk) 02:54, 9 October 2017 (UTC)

Removing "mount skin = Category:Mount skins"[edit]

There is redundancy in the mount skins categories. The Banded Mystic skin, for example, is within the categories "Mount skins" and "Jackal skins", but that's redundant - all Jackal skins are mount skins. The "Jackal skins" category is due to manual input, but the "Mount skins" category comes from this infobox. I suggest removing the automatic "Mount skins" categorization from this infobox, so those articles are categorized by the type of mount they're a skin of. For example, the jackal skins would be within the "Jackal skins" category, which would be within the "Mount skins" category. Erasculio 00:39, 18 November 2017 (UTC)

I've added the option to include "mount type = <jackal/griffon/whatever>" to the infobox to auto categorise it properly. Example If no mount type is set then it defaults to the "Mount skin" category. J.Tesla (talk) 12:46, 18 November 2017 (UTC)
Nice! Thanks. Erasculio 12:53, 18 November 2017 (UTC)

Why is there no way to mark an item(resource) that can go into material storage?[edit]

Or is there, and it's just not used? (Or maybe I missed it?) It is something that IMO is sorely missing, maybe there is a pattern, but I don't see it, so I'm constantly overwhelmed by the amount of information (and crafting resources) in the game/wiki.

Point in case: Pile_of_Pumpkin_Pie_Spice and Pile_of_Cinnamon_and_Sugar . Can you tell which goes into storage?--Cyberman 16:38, 4 February 2018 (UTC)

Well we already silently store whether it can be stored or not. Added. -Chieftain AlexUser Chieftain Alex sig.png 18:08, 4 February 2018 (UTC)
Great! Thank you, that's perfect.--Cyberman 16:39, 5 February 2018 (UTC)