GuildWiki has been locked down: anonymous editing and account creation are disabled. Current registered users are unaffected. Leave any comments on the Community Portal.

Hello there! We are conducting a survey to better understand the user experience in making a first edit. If you have ever made an edit on Gamepedia, please fill out the survey. Thank you!

Template talk:ItemInfo

From GuildWiki
Jump to: navigation, search

Item Info initiation[edit source]

In the process of building this, I did refer to GWW's version for inspiration. Obviously I didn't copy everything directly, not just because of licensing, but because there are some things that I just feel should be done differently. These are my notes about the various things I considered:

Style 
There are significant differences in style, mostly because our infobox styles are relics from 2005. We're probably due for a style overhaul, but that would be a huge job, and I'm not very good at graphic design.
Bundles 
GWW uses the same template for both bundles and inventory items, but I think it would be better to have separate templates.
Auto-rarity 
Their template goes to great lengths to set an item's rarity, if not specified, based on the item's type. I didn't see much value in doing this, especially since most of their cases ended up being "Common" anyway.
Auto-type 
Their template does a little bit of auto-typing based on the presence of other parameters, but it doesn't seem very robust (it includes typing of alcohols but not sweets or party favors). We could include this and make it more robust, or we could simply require the type parameter to be specified.
Value 
GWW displays "Can't be sold" if an item has a value of 0g. While it is true that you can't sell items worth 0g, displaying a string instead of the numeric value seems like a waste of text.
Runes/Insignia 
GWW has properties in their box for runes and insignia, but we don't have individual articles for those. Maybe we should?
Collectors 
GWW lists the collectors for trophies in the box. I couldn't decide whether this was a good idea or not, so I've left it out for now.
Profitability 
We include a property for trophies that indicates when it is more profitable to trade the item to a collector and sell the reward than to sell the trophy itself.
Common/rare salvage 
GWW's box does not couple these properties, such that an item with only a common salvage will not display a rare salvage property, and vice versa. I think it's important to always display both together, even when one of them is "None", so that readers know this is not simply an omission.

Dr Ishmael Diablo the chicken.gif 19:09, August 3, 2010 (UTC)

This is nice. Are you planning to roll this out to all item pages? -- RandomTime 21:13, August 21, 2010 (UTC)
Eventually, yes. The original impetus was, of course, this, so I'd probably do an initial rollout to trophies only. If you've got any more-specific feedback, I'd appreciate it. —Dr Ishmael Diablo the chicken.gif 22:12, August 21, 2010 (UTC)
Just made one change for style: I removed the colons from the header/label cells, since my solution for including numbers with the salvage info uses a colon between the material and the number.
ItemInfo font-size 90%.jpg
I'm thinking about advocating one further style change: a reduction of the font size. If you look at the current version of Moon Shell, the infobox is quite wide due to the line: "Common salvage - Pile of Glittering Dust: 6-8". I used Firefox's Web Developer add-on to preview it with the size reduced to 90%, and you can see the results in the image to the right. Jink agrees that it looks good, and much better than with normal font-size. —Dr Ishmael Diablo the chicken.gif 03:30, August 23, 2010 (UTC)
Awesome stuff. I heartily approve of all of your evolutions of the GWW design (I especially agree about common/rare sal and value.) What do you need from the rest of us to help make use of these, convert?
Here are my comments/ideas:
  • Runes/Insignias: We don't need individual articles, but perhaps we could jump to e.g. Rune#Vigor on the page.
  • Can we use this for weapons & armor by adding their special data? Or is there a reason we have separate templates for uniques, shields, bows, costumes...
  • Can we mark the sweet, party, alcohol templates as deprecated?
  • Same for salvage items, collect drop?
  • For profitable, I'd like us to include the value/item if sold, e.g. 40Gold/kournan pendant. The variable could accept Yes, No, or a number (that would display with the gold icon).
  • Collectors: I think the infobox could just include a "Yes" or "No" — the actual collectors are going to be detailed in the article. I don't see much value by listing their names at the top.
  • Icons (picture = 999 words):
    • whenever there's a yes/no/na/none, can we use the PNG files from {{tick}}? e.g. Profitable: Nope.png instead of Profitable: No)
    • I like the 90% font for e.g. Pile of dust, but mebbe we could just use the icons?
Thanks for making this happen.  —Tennessee Ernie Ford (TEF) 18:23, August 25, 2010 (UTC)
Response:
  • Runes/insignia: I think you misunderstood me. I mean that GWW's infobox includes code for rune-specific information to be displayed on the individual rune articles (similar to alcohol- or sweet-specific info); there's nothing that would link to runes from other articles.
  • Weapons aka equipable items: While it would be possible to expand this template further to include equipable items, I would recommend maintaining separate templates for a number of reasons.
    1. Other than campaign and salvage info, the other parameters they would use from this template would always have the same values — rarity: varies/unique; value: varies; stackable: no. With their own infobox, we save space by omitting this "common knowledge" completely (like we currently do).
    2. The additional parameters they require wouldn't be used at all by non-equipable items — linked attribute, damage type, PvP reward level, skin (for uniques).
    3. The primary infobox image for equipable items should be a screenshot in .jpg format, but this template is designed for an icon in .png format. On GWW, their boxes can include both, but in opposite positions: equipables have a render/screenshot at top and the icon at bottom; non-equipables have an icon at top and a render at bottom.
  • Armor/costumes: See above.
  • Deprecating other templates: Yes. This would replace Alcohol, CollectableDrop, CraftingMaterial, PartyInfo, QuestItem, SalvageItem, and SweetInfo, as well as the horribly old-fashioned Item box and Salvage box template sets.
  • Profitable: I'm not sure how practical that would be to implement, and it certainly wouldn't be intuitive to read. For many of them, you'd have to explain which collector to trade with (Frigid Heart) or explain which item to trade for (Kournan Pendant) under Notes anyway, so I'd rather leave that out.
  • Collectors: Eh, including it as a boolean would seem pointless. With the sell value and salvage info absorbed into the infobox, the articles for most trophies are going to be short enough that you could immediately see if there are any collectors listed or not.
  • Icons:
    • Ticks: Why? I'd be worried that the bright colors would be too distracting. They're useful in tabular data where a colored identifier is easier to pick out than a purely textual one, but I don't think there's really a need for them here.
    • Materials: Eh, I dunno. They work in crafting tables because we use them at 25px, they mirror what you see in-game at the armor crafters, and because they're used throughout the table. Here, they'd have to be smaller, especially if we go with 90% font size (which I'd really like to do now), probably about the same size as in the Material Storage pane, which I find somewhat difficult to use. The in-game "proof" that you salvaged something is a text message that says, "You salvaged X Materials from..."; you don't really notice the material in your inventory, unless it creates a brand new stack. Finally, they'd just be a handful of icons in an otherwise textual infobox (the gold icon is ubiquitous enough that it gets exempted).
While I disagree with most of your ideas, I thank you for making me think about some of the implicit decisions I'd made when developing this. —Dr Ishmael Diablo the chicken.gif 20:32, August 25, 2010 (UTC)
Hey, that's my role as a gadly :-) — to make sure we've thought through rather than accidentally decided.
I'm fine with all of above except for three things:
  • Profitable — I doubt that would be hard to do (the data is already avail). Naturally, ppls are going to have to read more; the point is to let them know if it's worth doing so: people would be less likely to investigate if the item only nets 5Gold after all the farming/storage/transactions.
  • Collector boolean — same idea; there are lots of collector-less items — it would be nice to know if it's worth scrolling down to take a look.
(if we included both, that information can be used to present lists/tables elsewhere in the wiki)
  • You didn't mention how we can help.
And, I don't think it can be said often enough: nice work.  —Tennessee Ernie Ford (TEF) 20:47, August 25, 2010 (UTC)
Doot-doot-doot.
  • Profitable: I was talking about the practicality of making your idea work within SMW, not the practicality of collecting the data. (I was the one who initially compiled it 3 years ago, so I know it exists :P ) As a boolean, the values for this property are standardized: SMW can understand yes/y/true/t/1 for true and no/n/false/f/0 for false, all case-insensitive. This makes it simple to include the property in a query to filter the results by [[profitable::(yes or no)]]. If we change it to a string, the standardization is lost, and the semantics of the name are somewhat diminished: when you ask, "Is this profitable?" you expect a yes/no answer, not a number. When querying for profitable items, you'd have to do [[profitable::!No]], which isn't as obviously logical (why use a double negative?), and since it's not standardized, you can't be certain that someone didn't set the value to 'N' or 'no' or even 'Nope'.
  • However, it might be useful to create a separate property for the profitability value... but someone else is gonna have to come up with a semantically sound name for it, I can't think of anything that sounds good. This would let you filter queries by exactly how much profit you can make on the item, which might be useful for someone who's really bored and feels like making money by farming trophies.
  • Collectors: But you won't have to scroll to see that, is what I'm saying - the article will be short enough that, on "usual" resolutions, the Collector section will already be on-screen when the page loads. [edit] Oh yeah, and you can also see in the ToC if there are any collectors listed.
  • Help: Um... I don't know. Feedback from more people would be great, of course. I've already tabulated all the data for trophies in a spreadsheet, and I'll be rolling that out on my bot account to avoid RC spam. I guess if someone really wanted to double-check all the data, I could email them the spreadsheet. Or you could start compiling data for other item types.
Thanks. —Dr Ishmael Diablo the chicken.gif 21:53, August 25, 2010 (UTC)
Collectors: ok, I'm (almost completely) convinced.
Profitable: ah, I didn't understand it was a boolean/booleanish choice. I'm sure you considered, profit per item for a variable name. My imagination says it would display:
Profitable: Yes (10Gold/item)
Taking a cue from collectors, an alternative might be to add a separate section (when relevant), == Profitability: 40Gold/item ==, which would be seen from the ToC. Does anyone else have an opinion? Care?
re: Help. Feel free to email me a macro-less excel (or display it in Google Docs). I can compare it to the data I've collected from GWW.
As an aside, I've kept the data b/c of my interest in things like, "is it worth the storage slot b/c I can get a useful collector's weapon? make book on holidays? should I sal or expert sal? It's not 100% complete or accurate, alas.
Re: Help. Should I start marking up the docs for the above templates to note that they are deprecated? (Won't matter much, but that is one task I can take off your hands.)  —Tennessee Ernie Ford (TEF) 22:45, August 25, 2010 (UTC)
Profitable: Meh, I should've thought of that name - my brain was off on other tracks with all this discussion. How about simply "profit" for the parameter, and "profit per item" for the property? Unless you think the parameter should be more specific. I think displaying it in the box like that will work fine, maybe adding a '+' to make it obvious that this is additional moneys, (+10 Gold/item).
Help: I just realized that I haven't added the Nick data yet. I'll do that after dinner, then send it to you. On the old templates, I would wait on deprecating them until they've been fully replaced, but I don't mind handing that task to you. —Dr Ishmael Diablo the chicken.gif 00:11, August 26, 2010 (UTC)

interlude: data quality[edit source]

I've checked the quality of Ish's data — looks spot on (I only spot checked file names and common mats; I checked names, plurals, rare mats, and a few other things in detail.) Well done, Ish.  —Tennessee Ernie Ford (TEF) 02:40, August 26, 2010 (UTC)

Other params[edit source]

We've narrowed down the questions to profitability... and have an answer. In reviewing the xls data, I found three more things that I collect, but are not params (yet):

  • Does collector offer max weapons? Y/N
    (I don't bother w/max armor b/c it's not truly max, since it cannot be fully upgraded.)
  • Is there a holiday collector? Y/N
    (I also try to determine the "value" of converting the item, e.g. assuming 100pg/sweet etc, but that's probably beyond scope of wiki.)
  • Salvage items that sound like a trophy: should we also put them into this template? They have a lot in common with trophies. This includes things like Roaring Ether Hearts, Spider Webs of all sorts, carapaces of some sorts, various hides, and shipment/stolen salvages that are easily confused with shipment/stolen trophies.

I think these would be useful to add. If you agree, I could add the data to your table. (Although, perhaps it would be easier in a second round.)  —Tennessee Ernie Ford (TEF) 02:40, August 26, 2010 (UTC)

The first two would be properties of the collector, not the item, so it wouldn't make any semantic sense to add them here. Make a note of them so we remember when we (hopefully) get to that point. However, you made me remember something else that I've been thinking needs to be done: create articles for the individual Halloween collectors, like we have for the Wintersday ones. Add that to the "what can we do to help?" list. Are there any other festivals that have collectors like that? I don't think so...
Anything specifically marked "Salvage item" in-game is a salvage item, there's no ambiguity there. Trophies are ambiguous because they don't have an in-game designation, which is why we have the 'collectable drop' vs. 'trophy' dichotomy between the wikis (which, if you haven't noticed, I've been attempting to rectify by using 'trophy' exclusively throughout this project). The only real issue is with items like Charr Hide, which is designated a "Salvage item" but also has a collector NPC. For the purposes of the infobox, we should follow the in-game designation (if the item has one), and we can manually add the item to additional categories and set additional Item type::x properties if we need to. Charr Hide is in my spreadsheet because I copied the article list from Category:Collectable drops, and this consideration never crossed my mind; I'll go remove it now.Dr Ishmael Diablo the chicken.gif 03:28, August 26, 2010 (UTC)
While I see the SWM technical point, I'm saying that as a player, I want to go to the item page and, with the least amount of work on my part, determine if the item is worth a slot in storage. As a player, I have no interest that Charr Hide is a salvage item b/c I can get more fur from it by giving it to a collector. As a player, it doesn't matter to me that the collector is what determines if an item belongs Category:Holiday items — I'm only interested in the fact of its holiday-oriented collectibility. (Anyhow, I'm not so much arguing with your point as I am asking, "ah, well what can we do to ignore that persnickety little fact?")
Re: I otherwise approve of your plan to make things plain (collectible drop — sigh).
Re: Holiday articles (and what else needs to be done).
  1. As you note, only H'ween and Wintersday have known collectors (special events sometimes do, but those are, well, special).
  2. Canthan New Year's has a sort of collector: the chefs (for precious minutes, you can give them items in exchange for loot), but they already have articles.
  3. Our existing articles could do with some severe tidying up: we distinguish sometimes between years (and other times not), even when there are no differences (that couldn't otherwise be mentioned in Notes), we have used differing formats among the holiday collectors, etc.
  4. We use the same format for holiday collectors as for persistent ones, which causes IMO two issues: (a) we give equal weight to both, even though one type isn't available year-round; (b) shouldn't the holiday collectors be more festive looking anyhow?
I'm going to give some thought to how that might be handled, perhaps with optional collector parameters, Halloween, Wintersday, that would affect the css used in the table.
 —Tennessee Ernie Ford (TEF) 04:25, August 26, 2010 (UTC)
Discussion about holiday stuff should probably be moved somewhere else (perhaps the CP?), since it's really off-topic for this talk page.
2. They're different enough that I wouldn't call them collectors. Scrappy Jhim and the Imperial Sorcerers are similar, except you give them a bundle item instead of an inventory item. They act more like quest NPCs to whom you are delivering something. (Or maybe we should include, say, Ruthless Sevad as a collector because he "collects" 5 tarnished platinum coins?)
3. I thought I had completely eliminated that "listing every year" business some months ago. Who did I miss? As for differing formats, the one that comes to mind is the Candysmiths, e.g. Candysmith Noel. The "image gallery" style feels really weird, mostly because it doesn't look anything like the usual collector rewards table, thus creating a disconnect between them and all other collectors.
4. Same formatting gives "equal weight to both" festival and non-festival collectors. I don't think that's really an issue. On the item's page, that collector should be placed under a sub-heading of "Special event collectors" or similar, like on Charr Carving, and that's good enough. (That would remove the need to mention festival collectors in the infobox, as readers can see from the ToC whether it has "Special event collectors" or not.) We do need to ensure all SE collectors are actually listed on the items, e.g. Hardened Hump doesn't list Necromancer Kalvori. Making the festive collector's reward table "more festive" would result in making them stand out and seem more notable/important in comparison to the other collectors for the same item. If you want festival NPCs to look "more festive," that should probably be done with a custom NPC infobox, not by modifying the collector rewards table.
Dr Ishmael Diablo the chicken.gif 20:02, August 26, 2010 (UTC)

Pilot rollout this weekend[edit source]

I believe that all pertinent issues directly related to this template have been resolved (the only open questions above relate to collectors, not items). As such, I am going to start rolling this out to all trophies tomorrow. I hope to have the system in place by Monday so that we can deprecate the old template system for Nicholas (assuming he doesn't decide to be a jerk and collect a rare mat or salvage item). —Dr Ishmael Diablo the chicken.gif 18:39, September 3, 2010 (UTC)

If you're talking about the traveler, he's already collected rare mats. (Nicholas_the_Traveler/Past_Collections 6/22/09) --JonTheMon 18:54, September 3, 2010 (UTC)
Um, I know that - I meant if he decides to do one this Monday. —Dr Ishmael Diablo the chicken.gif 19:20, September 3, 2010 (UTC)

Pilot rollout is complete - all trophies have been updated to use this template. —Dr Ishmael Diablo the chicken.gif 21:58, September 4, 2010 (UTC)

I've done some spot checking — looks pretty good to me, esp. the "Nick asked for this once" section. Thanks for putting together the template and standardizing so many pages to make it fit together.
I also like what you've done with trophy vs reward trophy etc. (As you know, as a player, I draw less distinction between trophies and trophy-like salvage items, but I think you've done a super job of outlining ANet's categorization so it's understandable w/o a PhD.)  —Tennessee Ernie Ford (TEF) 07:26, September 6, 2010 (UTC)
Given the lack of comments/complaints, I'm going to assume everyone likes this new format and roll it out to all items, starting with reward trophies, salvage items, and crafting materials. —Dr Ishmael Diablo the chicken.gif 14:28, September 20, 2010 (UTC)

Traveler date[edit source]

This may be more helpful if the feild made it apparent that the traveler date is listed week beginning, or also list the time when he stops collecting. -- RandomTime 12:07, September 4, 2010 (UTC)

Changed "Date" to "Week of". Better? —Dr Ishmael Diablo the chicken.gif 12:42, September 4, 2010 (UTC)
Yes indeed -- RandomTime 17:17, September 4, 2010 (UTC)

Item typing and semantic concepts (discuss!)[edit source]

After doing some more work/research on this, I'd like to propose a change to the way that item types are handled in light of the capabilities offered by SMW.

In brief, I think we should use the {type} parameter to describe only the most basic classification of the item, i.e. it should be a direct subcategory of Category:Items (that category tree will be getting an overhaul throughout this process). I've come up with a classification scheme for these basic types which I've posted as the description for Property:Item type. Let me know if I missed anything there.

To handle item subtypes, there are a couple options:

The old way: Specify it explicitly by adding a {subtype} parameter to this template. The existing sub-sub-cats would be maintained, and the item would be auto-categorized based on the value of this parameter.

The new way: Replace the sub-sub-cats with semantic concepts. Concepts are basically cached queries stored in their own namespace (Concept:) that mimic categories. These would take advantage of the semantic properties set by this template to implicitly build the list of items for each subtype. Some examples:

  • Concept:Salvage remains = (Category:Salvage items && stackable == yes)
  • Concept:Alcohol = (Category:Consumables && potency > 0)
  • Concept:Tonics = (Category:Consumables && article name =~ /Tonic/)

We could even expand on the current subtypes with more detailed concepts, like:

  • Concept:Strong alcohol = (Concept:Alcohol && potency == 5)

Concepts could also replace the contains/requires/drops <material> categories (this is actually the very first use I thought of when I learned about concepts), but that's getting a bit beyond the scope of this section.

To bridge the gap between item-type categories and item-subtype concepts, we could either 1) add a section to the category description with links to the concepts that replaced its former subcats ("This category is related to the following concepts" or something), or 2) categorize the concepts into the item-type category, like I did with Concept:Salvage remains. 2 is simpler, but doesn't allow for an explanation of what the concepts mean; since this whole idea is basically new to this wiki, we'd probably want an option that lets us explain the new features. —Dr Ishmael Diablo the chicken.gif 21:08, September 10, 2010 (UTC)

I'm not sure I understand how the reader would see the wiki differently and/or how it would be easier (or harder) for the casual contributor to help maintain this. I think what you are saying is that our current categorization forces us to consider type and category for each/every relevant article. The SMW method would allow us to keep those distinct: keep the typing relevant and we can create any type of categorization that is useful to us (or, I suppose, create dynamic lists when that serves us better than a category page).
Can you take two specific examples (e.g. Aged Hunter's Ale and Silken Spider Web) and compare what data is in the articles now and what would be there after? And then, under SMW, what could we do differently/easier? I was trying to type out what I thought would happen and realized I'm not clear enough about the idea yet.
(If this is going more/less in the direction I think it is, it sounds like a great idea that could make things much easier in the future, e.g. if there's a another Guild Wars Beyond effort and if there's ever a GWiki2.)  —Tennessee Ernie Ford (TEF) 21:34, September 10, 2010 (UTC)
One other idea I forgot to mention before: under "the new way", this template would be updated to include code for determining the most common subtypes (i.e. the ones we already have categories for) and display that as the first "property" in the infobox, immediately under the primary type (so that right under the large "Consumable" it would have "Subtype : Alcohol"), as a link to the concept. This would serve to keep a direct link on the page to the subtype, since it would no longer have the category link.
Aged Hunter's Ale
  • Currently: in Category:Alcohol (a subtype)
  • Future: in Category:Consumables (a primary type), infobox Subtype links to Concept:Alcohol
Silken Spider Web
  • Currently: in Categories: Salvage Items | Salvageable Remains | Contains dust | Contains silk
  • Future: in Category:Salvage items, infobox Subtype links to Concept:Salvage remains.
The big difference is that most articles would have fewer categories, and the categories they do have would be broader. For the most part this is a good thing, since it reduces clutter in the page's category list and reduces the complexity of the wiki's category tree. The bad part is that the categories are broader, but that's why we'll have to make sure that the concepts (which are replacing the more-specific categories) get plenty of exposure. —Dr Ishmael Diablo the chicken.gif 15:44, September 20, 2010 (UTC)

I've gone ahead and added subtyping code to the template. The selection tree it uses is given below, based on the primary types given at Property:Item type. Types not listed do not have any subtypes.

Salvage item
Salvage armor (stackable = no)
Salvage remains (stackable = yes)
Trophy
[none] (common salvage = not null)
Reward trophy (common salvage = null)
Consumable
Alcohol (potency = not null)
Party favor (festiveness = not null)
Sweet (sweetness = not null)
Kit (name =~ /Kit$/)
Scroll (name =~ /Scroll/)1
Summoning stone (name =~ /Summoning Stone$/)2
Tonic (name =~ /tonic$/i)
  1. I'm not really concerned about the other name-based subtyping, but this one could potentially return false positives since "scroll" is a more commonly-used word in item names. However, since I'm restricting the subtyping code to only items with the main type (i.e. only Consumables can be subtyped as Scrolls), I'm pretty sure it won't happen.
  2. ...And we already have an anomaly, the Shining Blade War Horn doesn't match the naming scheme of all the other Summoning Stones. Thus I had to add a branch to allow a {subtype} parameter to be passed explicitly.

Is there anything at all that I might be missing from this list? —Dr Ishmael Diablo the chicken.gif 15:44, September 20, 2010 (UTC)

Well poop. We can't currently do any of the concepts based on name patterns because SMW's "like" comparator has been disabled by Wikia. The template code can do it fine using #pos:, but we can't replicate that in SMW queries. The question is whether it's worth bugging Uberfuzzy to get this enabled for us (I don't think he likes me much right now, what with all the complaining I've been doing about the thumbnail and skin issues) or whether we should just stick with the old method of putting these in categories. A third option would be adding one-off properties simply to define summoning stones/scrolls/etc. (would be a boolean like Property:Is summoning stone = yes), which we could then reference in SMW queries, but that feels clunky. —Dr Ishmael Diablo the chicken.gif 16:01, September 25, 2010 (UTC)
Yes, we should bug Wikia. We took the time to implement an add-on and have taken the time to edit numerous articles assuming its full functionality. (Well, mostly Ish has taken the time, but the point remains.) I don't think it is reasonable that we have to work around Wikia (unless there's a darned good reason...and, in my experience, there hasn't been one yet).
Whether wikia staff like us or not shouldn't be a factor in wikia doing the right thing.  —Tennessee Ernie Ford (TEF) 16:14, September 25, 2010 (UTC)
It is a potential performance issue - string-based searches with wildcards can, in some cases, be very processor-heavy. However, I would assume this is implemented using SQL's LIKE function, which is actually optimized very well in most database implementations. It would be much worse if this were a regex-based search (which DPL supports), but it's not. So unless we went completely crazy with it, I doubt Wikia would notice any performance issues at all. —Dr Ishmael Diablo the chicken.gif 16:56, September 25, 2010 (UTC)

'Package' subtype[edit source]

One subtype I forgot to mention above is "package." (GWW calls them Presents, but I think it would be better to use a more generic term that's more descriptive of their actual function (they contain things).) While it's obvious to a human what items fall under this type (they turn into other things when you double-click them), there's not an easy way for SMW to determine this, since, unlike summoning stones or tonics, the items don't follow any standard naming convention. Which makes defining a Concept: for them difficult.

A possible solution that's actually an extension of another idea I've been thinking about is to take each entry in the Contents/Rewards section and turn it into a semantic property definition, something like [[Package contains::Red Rock Candy]]. We could even set this property up as Type:Record so we could record the quantity with it like [[Package contains::Red Rock Candy; 5]]. This would let us define the Concept: as simply [[Package contains::+]]. (This idea has plenty more uses, my initial plan was to use it for [[Drops material::xxx]].) —Dr Ishmael Diablo the chicken.gif 19:55, September 25, 2010 (UTC)

Quest property[edit source]

The quest property doesn't automatically turn into a link. I'm going to populate these items without a link; Doc Ish can decide whether to bot the links or update the template to auto-link.  —Tennessee Ernie Ford (TEF) 03:39, September 22, 2010 (UTC)

I left it without a link for two reasons:
  1. There may be some items that are required for more than 1 quest (I can't think of any offhand, but there might be)
  2. Some "Quest items" may not be related to an actual quest, in which case we might want this property to be plaintext.
Dr Ishmael Diablo the chicken.gif 03:45, September 22, 2010 (UTC)
Oh, so I should start linking them :-/
Ok. I'm actually going to stop with the few I've done so far, so that (a) you can spot check them; (b) fix anything what needs fixing; (c) update the template doc (based on your observations on a/b). I'll continue where I left off later on tonight. (Factions quest items)  —Tennessee Ernie Ford (TEF) 03:56, September 22, 2010 (UTC)
Made some updates to the doc. The only issues were not linking the quests and including blank parameters. —Dr Ishmael Diablo the chicken.gif 04:14, September 22, 2010 (UTC)
Ah-HAH! I knew there was something that got used for 2 quests: Nong Berries (although it's actually 2 different items) and Stone of the Elements (makes me wonder if that is also 2 different items). —Dr Ishmael Diablo the chicken.gif 15:25, September 22, 2010 (UTC)
Yeah, I would argue that since they don't stack with each other, they are different items. I certainly don't think it's worth having two articles to accommodate it, but (a) maybe we could stick with assuming one quest item, one quest and (b) do something special for these two.
However, I think this is a question worth postponing for a later day (even, in the unlikely situation, that you agree with above). The current plan works, if we change our mind later, a bot can fix the brackets, etc. This detail isn't going to make/break the template.  —Tennessee Ernie Ford (TEF) 21:50, September 22, 2010 (UTC)
Splitting the articles would be preferable, IMO, especially for something like Mysterious Message (item) which is used for 2 quests in different campaigns. If any of these items had different icons it would be an easy argument to split, but I think we can live with the combined articles for now. —Dr Ishmael Diablo the chicken.gif 21:55, September 22, 2010 (UTC)
Mysterious Message (item) is an abomination of ANet's fact checkers. There are far too many examples where developers clearly intended a new item, but used an existing name. (Fortunately, they mostly did it with relatively unimportant weapons and only screwed up a few unique weapons and a minor number of quest items.) In any case, let's try to remember to review all such quest items in a month or so.  —Tennessee Ernie Ford (TEF) 22:00, September 22, 2010 (UTC)

Everlasting festiveness[edit source]

Ponder: should we specify in the infobox that Everlasting Tonics give 0 festive points? This would eliminate the need for a textual note, and would ensure that they get included in the Party favors concept. It feels a bit odd to be setting a property like this to 0, but we're already setting Value to 0 for items that can't be merched, so that's no issue. Just leaving this note here to explain my thought process on this decision. —Dr Ishmael Diablo the chicken.gif 20:40, September 24, 2010 (UTC)

/agree. They are only distinguishable from other party favors if you know how Party Animal works. So: yes, include them in the concept with a 0 value for their contribution.  —Tennessee Ernie Ford (TEF) 23:27, September 24, 2010 (UTC)

Merged (quest) items and the template[edit source]

A couple of quest items have been merged into single articles. So far, I've found:

I'm sure there are others, but these two came up. There's also no question that these are different items with the same name (as there might be with the berries that are used in a Factions newbie quest that fail to stack with the ones used in a Canthan New Year activity).

This is obviously sensible as far as article management goes, but how do should we handle it for item info? Should we put an {{ItemInfo}} for each actual item? Is there any easy way to accommodate this? Obviously we can choose something that will work for now and change it later.  —Tennessee Ernie Ford (TEF) 08:03, September 29, 2010 (UTC)

Why not split the articles? Putting >1 infobox on the same page won't solve anything, especially for the Map Pieces - SMW associates all properties with the page name. —Dr Ishmael Diablo the chicken.gif 13:28, September 29, 2010 (UTC)
Spilt and disambig is what I'd expect. --◄mendel► 15:11, September 29, 2010 (UTC)
These are hella short articles, so I hate to add more of them. Especially since it would mean have a disambig message that is nearly as long as the text of the article (that readers would have to parse to determine if they found the right page...and follow a link if not). Would the SMW still work if we:
  • Created the new articles
  • Add {{ItemInfo}}
  • And also put a redirect at the top?
The idea is sort of a best-of-both for readers (kind of annoying for contributors only)  —Tennessee Ernie Ford (TEF) 15:28, September 29, 2010 (UTC)
There's nothing wrong with short articles, especially when you're documenting a game with hundreds of items that don't have any special function.
As for the disambig message, the Mysterious Message pages would just need to link back to Mysterious Message, the main disambig page - you wouldn't have all 4 articles list each other in their DisambigMsg. We could do the same thing with the Map Pieces.
While your idea would probably work, I think it would be just as confusing for readers as it would be for editors. —Dr Ishmael Diablo the chicken.gif 15:54, September 29, 2010 (UTC)
No worries — if you two aren't worried about adding another dozen or so tiny articles, I will stop losing sleep over it.  —Tennessee Ernie Ford (TEF) 15:57, September 29, 2010 (UTC)

Revisiting: Holidayness as a parm[edit source]

I would like to re-open the idea of indicating the importance of an item to holidays (and other not-quite-quest uses):

  • Charr hides have a non-holiday and a holiday collector.
  • Celestial essences do not have a collector; instead, they are useful to winning the feast mini-game in Canthan New Years (and provide a minor benefit to those turning them in).
  • Hard Apple Cider does not have a collector; instead, it is useful to Gwen/Thack picnic scavenger hunt.
  • Skree wings have a collector; they are also required for the Black Moa Chick scavenger hunt
  • Inscribed shards have only Nick as a collector and they are not a quest item; however 10 are required for a quest.

There are other examples of items that have non-quest, non-collector importance. I would like to make it easy for readers to find a way to (a) search for such items; (b) see their non-standard impact in the at-a-glance info-box; and (c) make it easy for us to keep things up-to-date as GW Beyond evolves to give us more of such headaches.

One specific way of doing that is to add 1+ parms to ItemInfo, e.g. non-persistent collector, used on holidays, mini-game uses, etc. Obviously, a lot of the details would end up remaining in Notes or Description.

(Obviously, this is not important enough to worry about before forking/moving. I want to make sure we consider this after things stabilize.)  —Tennessee Ernie Ford (TEF) 16:45, October 5, 2010 (UTC)

I don't feel that anything with a "non-standard impact" belongs in a standardized infobox template like this. That's the entire point of having an article in addition to the infobox - the infobox provides all the standard, this-could-be-tabulated-in-a-database information about the article, while the article text is where you list all additional information. Adding stuff like this would bloat the infobox beyond the point of usefulness. —Dr Ishmael Diablo the chicken.gif 17:04, October 5, 2010 (UTC)
Suppose you are a hoarder (as many of us are) and suppose you realize that you really must clean out your storage. Can't we make it easier to see that an item is useful but not in the usual ways? Otherwise, we force people to read through every item page to find out something almost obvious. As a case-in-point, I sold a lot of Hard Apple Cider even after we had articles documented its use in the picnic b/c I didn't find the special usage through any of my searches.
Or, put another way, standard uses come in various frequencies: common (collectible), uncommon (Nick collections), rare (profitable), and unusual (holiday, quest, scavenger, ...). We document the first three frequencies in the info box; why not one more?  —Tennessee Ernie Ford (TEF) 18:24, October 5, 2010 (UTC)