Guild Wars 2 Wiki talk:Community portal/Archive 9

This page is an archive. The contents have been moved from another page for reference purposes only, and should be preserved in their current form. Discussion or voting on this page is not current. Any additions you make will probably not be read.
The current version of this page can be found at Guild Wars 2 Wiki:Community portal.

linking to redirects - good/bad/who cares?

Recently, I've been reverted a couple times by our prolific anon (75.37.something) after editing a link to a redirect to point directly to the target page, e.g. [[push]] to [[knockback]] (or to [[knockback|push]] if in a skill description). I always thought it was bad practice to link to redirects, because it obfuscates where the link actually goes and can confuse readers when they get taken somewhere else. Piping a link takes very little effort, has a miniscule performance impact, and makes thing clearer for the reader as both the tooltip and the URL in their status bar will show the "proper" target page when they hover on the link.

So what's everyone else's opinion? Is it okay to link to redirects? Is it better to link directly to the target? Or is this a case where it doesn't matter, but don't revert just because you disagree? —Dr Ishmael 12:33, 18 June 2013 (UTC)

I hate being linked to redirects. It doesn't take more than 5 seconds to figure out where to link to and type it. -Chieftain Alex

12:53, 18 June 2013 (UTC)

There's absolutely no reason to link to redirects whenever you can pipe them to the correct page. I can't think of a single reason you'd link to the redirect itself. Vahkris (talk) 13:03, 18 June 2013 (UTC)

(Edit conflict) I probably haven't bothered piping links properly when editing on phone on multiple occasions and instead opting to link to a redirected page. Editing the wiki with touchpad keyboard isn't that bad in itself but certain browsers just can't make good use of editing function in general. I can't say I really care if a link gets redirected or not, but I don't think circumvating a redirect should be reverted at any case. Mediggo (talk) 13:04, 18 June 2013 (UTC)

Okay, when you're editing on a phone, that's a reason :) (it's much harder to edit properly on a phone), but there's no reason to change a proper link to the redirect when you're on a keyboard. It's actually in our general formatting guidelines not to link to redirects. Vahkris (talk) 13:09, 18 June 2013 (UTC)

I missed that line in the GF, thanks for the link. @Mediggo, I understand that some editors (knowingly or unknowingly) will link to redirects. It's not a serious enough problem to call them out for it.

Also, there is a specific case where redirects are created with the intent of being used, and that would be the GW2W: project namespace redirects. However, these are not mainspace and should not be used in mainspace, so they're a valid exception. —Dr Ishmael

13:14, 18 June 2013 (UTC)

I see one reason why you would want to link to a redirect. That is the case when you actually link to specific topic, which is currently not big enough to have its own article, so it is listed under another article. Example:Gemstone#Transmogrification

Transmogrification will probably never be interesting enough to have its own article, but when we would create a Transmogrification article, it should redirect specificlly to this topic. When you have such a redirect structure I would prefer to get linked to the redirect and not to gemstones. Because when we this topic gets interesting enough, we don't have to update links because all links to this topic already point in the right direction.

This is however the only half way relevent exception, where I would prefer a link to a redirect. - Yandere

13:33, 18 June 2013 (UTC)

I don't even think that counts as a redirect Yandere ^ I think its just an anchor - its fine to link to those though. -Chieftain Alex

13:54, 18 June 2013 (UTC)

Yeah, I wouldn't count that as a redirect, because it's not sending you to another page, just moving you down to a specific section on that page. Vahkris (talk) 14:04, 18 June 2013 (UTC)

Well, you learn new things every day, I didn't realize that this had a specific name. But yeah it makes sense because it works diffrent more or less. - Yandere

14:15, 18 June 2013 (UTC)

Yandere had a point, even though it seems like he got steered away from it - Rarity redirects to Item#Quality (and Felix just created Transmogrification to redirect to Gemstone#Transmogrification). These would also be acceptable to leave as links, partly for the reason Yandere stated ("when this topic gets interesting enough [to get its own article], we don't have to update links"), but also because in case the name of the header changes, only the redirect has to be updated. —Dr Ishmael

16:05, 18 June 2013 (UTC)

I agree, for topics like those which currently do not have their own articles, it is a lot easier for everyone to just use the redirect.

Another edge case I personally keep linking to redirects is capitalization. We all know how we want to capitalize stuff; unfortunately the game is rather inconsistent (despite their weird ruling they published back then). So, for example when I want to link to guild armorers inside a text, I will link to the redirect which uses our sentence casing. Yes, I could write [[Guild Armorer|guild armorers]] but this really bloats the wiki text for no good reason. It makes the text harder to read and as such harder to edit. The point of the easy link format in wiki text is to use links inside of the text without having to care much about how the article is actually named. If that means that we have to link to a redirect, then okay, let’s do it when it makes the text easier to edit. poke | talk 16:27, 18 June 2013 (UTC)

I can live with lower-case links, I suppose. What I'm mostly concerned with is linking to alternate terms, like push instead of knockback, in situations where it doesn't really matter which one is displayed, so the actual article name should be used. —Dr Ishmael

16:37, 18 June 2013 (UTC)

I think redirects should be used when its something either directly from the game like a skill description or patch notes where we want a link to something but anet uses weird wording. for example they say karka queen in patch notes all the time but her in game name is Legendary Karka Queen and karka queen is used more often in patch notes then legendary. I also think its appropriate to have redirects for things that people search for like kara queen instead of legendary karka queen.-

Zesbeer 20:16, 18 June 2013 (UTC)

Wrong topic Zes. We're talking about when a redirect exists, instead of linking to it, pipe to the destination page instead. As to the original topic, I think it's a "good vs better" thing. It's good that there's a link to an article, even through a redirect. It's better if you go straight to the article. --JonTheMon (talk) 20:24, 18 June 2013 (UTC)

(re-indent) It's harder for anyone trying to edit an article to read [[ability|abilities]] instead of just [[abilities]]. Using pipes to avoid a redirect makes the wiki less accessible to average players. Unless there's some technical reason to bypass a redirect, it creates extra work on everyone to avoid redirects. If knockback and push mean the same thing, then I can't see how it's better for the community to force everyone to type out the piped version whenever they want to use a synonym.

The less code there is in the article, the more likely someone new to editing will make the effort to change things. The more code there is, the more likely they will give up or maybe just type on the talk page, "I'm not good at editing." In fact, a lot of the new templates and technical changes do make things easier. The info boxes are easier to update. It's easier to add a row to a table. The new drop rate tables might have some issues, but they make it much easier for non-geeks to post their data. Using redirects for linking inside an article do the same thing: they allow non-coders to be part of the wiki community. 75.36.181.135 20:46, 26 June 2013 (UTC)

Bypassing a redirect is needed when a redirect then itself redirects somewhere else. Double-redirects fail / only leave a link to the next page. So, while it makes the code a little bit harder to read, it does have a (long-term) purpose. And while it is good to urge new editors on, I don't think in this area we need to coddle them. Linking is one of the first things they learn to do, and piping is a quick addition to that. And if we don't have any piping, how are they supposed to learn it? --JonTheMon (talk) 22:14, 26 June 2013 (UTC)

double-redirects: fix. Non-double redirects? It's not any more "coddling," than helping non-native-English speakers by using "has the same name" instead of "eponymous" in article text. 75.36.176.20 03:26, 1 July 2013 (UTC)

"The less code there is in the article" If that's your concern, then piped links are the least of your worries. The functionality is much easier to figure out than a template, and what's the first thing they'll see on most articles? An infobox. A big honkin' template. The presence of a few piped links isn't going to make much difference when compared to the impact of templates and other "higher-level" forms of wiki-code. —Dr Ishmael

03:37, 1 July 2013 (UTC)

overhaul of Template:Recipe

I started discussion for an overhaul of our recipe template at Template talk:Recipe#overhaul proposal. Please provide feedback there. Thanks! —Dr Ishmael 21:42, 18 June 2013 (UTC)

weapon/armor skins

I've pushed for the semantic of Fused weapon skins over Fused weapons as the weapon set consists of a set of skins instead of a set of weapons. However, we do end up with "Fused weapons" once the skin is used on a weapon. Therefore we have an actual Fused weapon set. ArenaNet also simply says "Fused weapons" for describing the skin set. It would be easier for people to refer to the skin sets as normal weapon sets for the article, while we organize "skin sets" separately "weapon sets".--Relyk ~ talk < 17:35, 24 June 2013 (UTC)

Article talk pages: to talk or not to talk

I don't really want to write walls of text on this topic, so I'll TL:DR. A big draw of GWiki was the informal talk pages. Sometimes they were used to talk about the article, sometimes they were just sounding boards for users to vent some frustration or talk about an update to a skill or quest. This mostly carried over to GWW - even with an increased userbase, it was fine most of the time. A few exceptions arose, namely dev talk pages, but still, on the whole, article talk pages were free game for chatting.
This wiki seems to be far more against it - saying "use the forums, don't discuss that content here." While that's all well and good... I think we're unnecessarily chasing users away if we do that. Unless a particular article's talk page is spammed to the point of uselessness (i.e., the profession talk pages pre-release) we should be a little more lenient letting conversations happen on article talk pages.
Am I just totally insane or does that sound like a decent idea? :p -Auron 13:05, 26 June 2013 (UTC)

So, instead of discouraging talking on pages here, make it known that conversation just happens better on the forums? 'Cause I could also see someone coming here, asking a question on a talk page and getting a pseudo response then.... nothing. Which would also be discouraging. But that system kinda still doesn't help the wiki retain users ("Go elsewhere!"). Well, being more lenient certainly can't hurt, imo. --JonTheMon (talk) 13:19, 26 June 2013 (UTC)

I actaully totally agree with Auron. I remember a Post on the Talk page for No More Secrets were some user said this reminded him of the movie Sneakers and I had to smile a bit because I had the same thought. I think the talk page later got deleted, which I found kind of sad becaue it didn't hurt to let the information stand there and I think it was a bit to obscure for the trivia section und the page itself.

Complains about skills etc. are a bit diffrent because the wiki isn't fequented by the developers, the forum is a far better place to dicuss these things. I think we should at least mention this once in all fairness because their frustation or their suggestions aren't heard here. Similar and more important are things which should be handeled by the support.

These are basiclly my thoughts on this. At the moment I am extremly tired so my English might be off. - Yandere

13:24, 26 June 2013 (UTC)

I agree, unless pages are actually causing problems and work against the goal of the wiki, I don’t think we should stop any discussion about anything. Just like we allow users to talk about anything on user talk pages, we should allow users to talk about content on talk pages. poke | talk 15:44, 26 June 2013 (UTC)

I think we should actually encourage more use of the talk pages, not less.

It's discouraging when the talk page is dominated by by posts about how the talk pages aren't supposed to be used for anything except discussing the article. What's the big deal? What does the wiki or the community lose by allowing polite discussion, even if it's somewhat off the direct topic?

Of course, there are many who might not realize that ANet doesn't read the talk pages. It's worth letting them know about the official suggestions forum, official bugs forum, in-game bug report tool, and only support can address individual account issues. But there's a difference between letting people know about resources and telling people to get the hell off the wiki's talk pages.

Note also that a lot of times people ask a question on a talk page that turns out to be helpful in figuring out how to present stuff in the article. User questions or complaints can help editors realize that some information isn't clear or presented in a way that everyone understands. 75.36.181.135 16:06, 26 June 2013 (UTC)

My feeling on this topic has always been that arena net devs do not read the wiki talk pages so any suggestions or feedback that gets placed there isnt seen (also cant be used due to copy right). Other then that, the wiki is not set up to have forum like discussions and it largely fails at doing so because of edit conflicts and how talk pages are formatted. and those are the reasons why I try and address the issue and then direct the person to the forums where feedback can be seen by anet devs and be formatted in a correct matter.-

Zesbeer 21:11, 26 June 2013 (UTC)

Is the expectation that these people may eventually become positive contributors if they are allowed to discuss and argue on talk pages? It cuts both ways, does it not? Actual article discussion and argument getting derailed by opinions about the game and balance, chasing away positive contributors? Manifold

22:44, 26 June 2013 (UTC)

I think 75.36.181.135 makes a good point in that talk page discussion can positively impact the article itself. Think about actual questions about something the article does not (clearly) cover. If you see the questions, and figure out the answers together on the talk page, it can be incorporated into the article, making that one better.

The other argument is that allowing free “chat” with other editors makes the wiki a much nicer place, and yes, this will very likely make people spend more time on the wiki. We really shouldn’t discourage talk page discussions unless they are individually impacting the wiki in a negative way. poke | talk 23:03, 26 June 2013 (UTC)

I haven't found one talk page that strays detrimentally off topic from the topic itself. There are plenty of tl;dr topics where people take to their podiums to rant about a certain skill or item, but they get a max of 1-3 responses by the time discussion moves on.--Relyk ~ talk < 02:22, 1 July 2013 (UTC)

API documentation namespace

ArenaNet would like to move their official API documentation from the forums to the wiki, essentially expanding our existing API articles. Obviously as the API is still growing, there will be a lot more documentation coming. Also, given that it will be an official documentation, they would like to lock down the write access, so only valid things will appear there.

I suggested creating a separate namespace, similarly to how MediaWiki.org does it for the MediaWiki API. This would allow us to lock down the namespace completely (talk would obviously be open for all), and restrict the write access to a separate user group of “trusted” API maintainers (including obviously the ArenaNet API developers).

The question is what we call that namespace. I suggested a simple plain “API:”, e.g. “API:Event names” for the event names API etc. Stephane however thinks that this could confuse people given that it could also mean that it is about the MediaWiki API and suggested “GW2API:” instead. I personally believe it’s unnecessarily verbose given that we document the game and the API is part of the game. But I wanted to invite everyone to this decision, so feel free to state your opinions! :) poke | talk 23:09, 9 July 2013 (UTC)

I think Stephane is correct here. If we had non-default namespaces across the board API would suffice, but for the most part we use MediaWiki conventions so something that could be confused with a MediaWiki namespace is not ideal.

23:14, 9 July 2013 (UTC)

I don't think there'd be much confusion. MediaWiki.org documents MediaWiki, so their custom API namespace is about the MediaWiki API; we document Guild Wars 2, so our custom API namespace is about the Guild Wars 2 API. Also, someone would have to be aware that there is a MediaWiki API before they could be confused, and most editors (even those who'd be interested in the GW2 API) probably don't know about it. —Dr Ishmael

00:07, 10 July 2013 (UTC)

Does anyone else have any opinion on this? I know the API is a very technical topic, but input from others than the standard technical guys on the wiki would be very appreciated! ;) poke | talk 10:19, 11 July 2013 (UTC)

I think that is excelent news. I would think an API Namspace would be good, as long as the API article in the mainspace mentions that we have such a thing. I think when somebody is really looking for a term like API they will probably first read the mainspace article. - Yandere

10:49, 11 July 2013 (UTC)

Unless you're some kind of mediawiki guru, you're not going to know about the "API:" prefix (and if you did, then you'd be looking for it on the mediawikiwiki not gw2wiki), so it would be perfectly fine to use this prefix for a namespace on our wiki. -77.97.208.117 12:21, 11 July 2013 (UTC)

@Yandere: We would probably convert API into a redirect to [[API:Main Page]], same as how mw:API redirects to mw:API:Main Page. ("Main Page" may not be the best page name, perhaps "Portal" or something.) —Dr Ishmael

13:05, 11 July 2013 (UTC)

If we are absolutely sure that this wiki will never use the actual MediaWiki API, then calling it just API seems fine. But if there's any chance we'd want MW API in the future, I could see it causing confusion.

***EAGLEMUT*** TALK 14:42, 11 July 2013 (UTC)

We already have the MW API, it's a built-in feature. However, we would never document the MW API on this wiki. —Dr Ishmael

14:54, 11 July 2013 (UTC)

Ahh, thanks for clarifying. In that case, just "API" is perfectly fine, I don't think anyone should expect this wiki to document the MW API. We could just put up a notice at the top of our main API page like: "If you're looking for MW API, check the documentation at mediawiki.org/wiki/api.".

***EAGLEMUT*** TALK 15:17, 11 July 2013 (UTC)

API: is fine in my opinion. We aren't going to be documenting the MW API anytime soon, and even if we were to do so, it wouldn't require its own namespace. Beyond that, if you're technically-apt enough to know that MediaWiki makes use of an API: namespace, then you are also able to just refer to the documentation that already exists there instead of looking around here for it. Aqua (talk) 19:29, 11 July 2013 (UTC)

A new layout

I would like to propose a new layout for the Community Portal that is more similar to the Main Page. Here is my mockup. Note that I've merged "requests for comment" into the design because I believe that having one page that links to all of the important discussions being had is better than having several pages with very similar functions. Aqua (talk) 19:33, 11 July 2013 (UTC)

To be honest, I don’t really like that; it feels a bit too crammed. Also the way it works editing it to add things is a lot harder, making it harder for new editors—which should be able to post things on the community portal too. Furthermore instead of merging RFC into this, I would rather like us to simply use the CP more for general wiki use. I wouldn’t object seeing content from Relyk’s newsletter here. poke | talk 20:05, 11 July 2013 (UTC)

Achievement articles

So, this somewhat started here but I want to elevate this a bit to get more attention. My opinion is that p a g e s l i k e t[[Strangers from the Sky (achievement)|h]]e s e are not really helpful. Infoboxes are meant to provide an additional quick reference aside to articles, but articles should not contain of infoboxes and nothing else. Most achievement articles are unlikely to be expanded ever into more than just a basic description. This is already covered by the achievement category articles, which might not be presented in the best way possible (something I’m working on) but at least provide all necessary information there is.

In any way, before additional empty achievement articles are created, I would like to get more input on what the community thinks about this. poke | talk 18:38, 17 July 2013 (UTC)

Agreed, all of the information displayed on these new pages was already displayed on the old pages, making the new ones rather redundant. --Sirrush

18:39, 17 July 2013 (UTC)

(Edit conflict) My stance on this is that achievement category articles should be used unless the achievement requires a long and thorough walkthrough and is not a temporary achievement. All achievement names should redirect to the achievement category article, with the obvious exceptions of those that do require their own page for explanations and guidance. While the specifics of what qualifies as a "long and thorough walkthrough" can be debated, it is definitely not an empty content space except for a description (such as the ones that poke has already linked). Aqua (talk) 18:43, 17 July 2013 (UTC)

(Edit conflict) Same as Aqua. ~ PheNaxKian talk 18:44, 17 July 2013 (UTC)

(Edit conflict) "Disagreed". 1) Separate pages allows to search from in-game using exact achievement name; having a ton of pages with just redirects seems redundant to me. 2) Separate pages allows to put comprehensive description, and if you think this is not necessary for most articles - I'll find what to write myself. 3) With infobox template we can add semantic properties, allowing to build your favorite category pages a lot easier. Btw, what for do we have e.g. skill pages if we can find almost all info on achievement category pages? MalGalad 18:54, 17 July 2013 (UTC)

As a compromise with Aqua's variant... we can use {{#set: property=value}} on pages with redirect, right? And those linked pages were blank because, oh sorry guys, I'm handling it all by myself and didn't get to point of filling them yet. —The preceding unsigned comment was added by Malgalad (talk • contribs) at 18:59, 17 July 2013‎ (UTC).

My primary point is that all those pages you created are empty. Usually those articles would qualify for deletion (by my understanding), because as said above, an infobox alone does not justify an article. If you created actual articles with content, then sure, but that’s not what is happening.

The first issue you mention is indeed a real issue. Every achievement should have either an article on its own (if its justified) or redirect to an actual part of the achievement category where the relevant information is available. Unfortunately those overview pages currently do not provide any useful structure (as said above: I’m working on that). The searchability is definitely an issue, but having an empty article does not solve the original problem: Getting information about an achievement. If I search for an achievement and get an empty article, then I don’t have any benefit compared to when I get the category overview page instead where at least some information is listed.

Your comparison with the skill list is a bad comparison because obviously every skill article contains more information than listed in that single row in the table. That’s not the case for the achievement articles vs. achievement category overview. poke | talk 19:09, 17 July 2013 (UTC)

(Edit conflict) poke pretty much covered everything I wanted to say. Aqua (talk) 19:14, 17 July 2013 (UTC)

(Reset indent) I've rewrote articles up to Kites of Caledon. If the achievement description is enough to get it - I created a redirect with only properties left. If there's something to say about getting achievement - I added it. Agreement? MalGalad 21:02, 17 July 2013 (UTC)

Yep, I think that’s a good start. Thanks!

As we are on the topic of achievements right now; I have been redesigning our achievement tables (on the category pages) a bit to be more in line with how it looks now in-game and especially to be more flexible with multiple tiers. Our tables usually had issues when there were more than 4 or 5 tiers and started to look really odd. To compensate that, I present you my working draft.

Ultimately I would like to merge the achievement overview section with the acquisition sections to have a combined section where both the overview and the acquisition information is available in the same location (or a link to the article). I’m not perfectly sure how I would try that, but I’ll come up with a whole draft of a completely rewritten achievement category page later. poke | talk 21:16, 17 July 2013 (UTC)

Uhum, I'll rearrange {{tl|Achievement infobox}} to reflect your suggested properties better. MalGalad 21:30, 17 July 2013 (UTC)

Setting properties on a redirect doesn't work, SMW ignores them.

{{#ask:[[Has meta::+]]}}

Notice that your redirect Sanctum Sprint (achievement) doesn't appear in the results. —Dr Ishmael

21:49, 17 July 2013 (UTC)

Well, then we have a problem... And this SMW behavior is not adjustable, I guess? MalGalad 21:56, 17 July 2013 (UTC)

We can use #subobjects to define each achievement directly on the category pages. That would work out well in conjunction with Poke's template. —Dr Ishmael

22:38, 17 July 2013 (UTC)

Looks interesting, but it will create even more mess on category pages. Also, subobjects can't be categorized :\ MalGalad 23:12, 17 July 2013 (UTC)

Who needs categories anymore? One of the goals of SMW is to make categories obsolete. Well... maybe it's not a goal per se, but that's what it practically does. Instead of having a plain old list of pages like Category:Jeweler recipes, you replace it with a query {{#ask:[[Requires discipline::Jeweler]]}} (visual) which you can expand upon with a semantic template {{recipe table|discipline=Jeweler}} to provide a lot of extra data about each result. —Dr Ishmael

01:24, 18 July 2013 (UTC)

I definitely prefer the vertical list of tiers. It avoids the large blank areas in the achievement tables from having tiers as columns, which is a chronic issue. I made an example on User:Relyk/achievement for sticking the guides in a collapsed table using current format, but listing the tiers vertically gives you plenty of room in the first cell.--Relyk ~ talk < 02:13, 18 July 2013 (UTC)

Here is my own suggestion (based off of poke's) for how achievement categories (and achievement pages) should be formatted. Note that I've completely eschewed the acquisition section; I'm leaning towards the philosophy of either the achievement acquisition is self-obvious from the description or it requires a more thorough explanation that can be explained on the page. Aqua (talk) 02:32, 18 July 2013 (UTC)

That looks really good Aqua! And yeah, I think I can agree with that. If we move the acquisition completely to achievement articles, then the issues probably disappear. poke | talk 08:18, 18 July 2013 (UTC)

Using some of poke's code I've managed to make the individual achievements (except for main headers and meta achievements) accessible through a template instead. Aqua (talk) 16:06, 18 July 2013 (UTC)

[[User:Malgalad/Template:Achievement|Ta-dam]]! Example of usage:

{{#ask: [[Has category::Slayer]]
| ?Has canonical name
| ?Has tier count
| ?Has description
| ?Has flavor
| ?Has title
| ?Has reward
| ?Has tiers
| link = none
| format = template
| template = User:Malgalad/Sandbox3
}}

MalGalad 17:57, 18 July 2013 (UTC)

That's still setting properties directly, not using a #subobject. —Dr Ishmael

18:26, 18 July 2013 (UTC)

Hm, as far as I understood, subobjects are working as pages, without creating the page itself. If there's something more, probably a sample code will help? MalGalad 18:46, 18 July 2013 (UTC)

*pokes the link I provided* —Dr Ishmael

19:01, 18 July 2013 (UTC)

(Reset indent) So, be gentle with the renewed Bazaar of the Four Winds (achievements) page, but do not restrict yourself if you have suggestions or remarks. I'll work with individual pages tomorrow. MalGalad 02:15, 20 July 2013 (UTC)

I guess I'll start with what I like. The use of the title icon was something I was planning on, so I'm glad that's implemented. I also agree that individual achievement totals should be in the table somewhere (although I dislike the placement).

On the other hand, there are a bunch of things that I really do not like. First of all, the return of the tiers header on every achievement is both unnecessary and disrupts the flow of reading. The bulky "this is the meta achievement" and "this does not count towards the meta achievement" things are also pretty bad and in your face. I feel like having a quick footnote would suffice. (And also the reason that Bazaar Ambassador gets a real header instead of a subheader is to indicate that it is the meta achievement graphically; if you read the description you realize that it is the meta achievement without any further explanation required.)

My own mockup will be up shortly in my sandbox. Aqua (talk) 17:30, 20 July 2013 (UTC)

Hm, what about having total AP count in the header row instead of Tiers? And as for metas, well, almost all categories except for the living story&events don't have meta achievement, but their first achievement will have real header, so it cannot be used a mark of a meta. Maybe... maybe: 1) category icon near the name with the title that it's meta; 2) Meta: prepending the description (e.g. Meta: Complete 16 Bazaar of the Four Winds Achievements.) As for other points you mentioned - acknowledged. MalGalad 18:26, 20 July 2013 (UTC)

"Needs an update" category

Just another crazy idea. We already have build number included to the patch notes page, right? And we decorate patch notes with {{skill icon}}, {{trait icon}} etc. So, the algorithm:

Change {{%smth% icon}} to {{%smth% update icon}}.
Create {{%smth% update icon}} based on {{%smth% icon}}, that sets a semantic property "Was updated in build = N", other functionality remains the same.
Change {{%smth% infobox}} so, that:
1. Infobox hiddenly stores build number of the last revision.
2. If the stored number is less, then the number set in "Was updated in build = N", it adds category "Needs an update" or "Out of date" or something like that (possibly add notes like "That %smth% was changed in the N build, see [[patch notes]]").
3. After revisioning the article, the man who did it sets the build number in the infobox to the actual one.

This will allow to easy track pages that needs an update, with a little effort of filling in build number. MalGalad 13:44, 23 July 2013 (UTC)

What you're talking about is semi-dynamic data - data that updates when a page is saved, but not in between - and that's not easy to implement, because by default the wiki will refresh all dynamic data whenever it parses a page, and this happens at least once per day (default cache expiration = 24 hours).

Also, it's not always true that when something is modified in a game update, that the page must be edited. A recent update modified the aftercast delay on a lot of skills, but since we don't document that on the wiki (yet?), those changes did not require any edits to the skill pages. Another example would be when a bug is fixed that wasn't documented on the wiki.

Furthermore, I've noticed a small group of editors who routinely go through and update skill/trait pages immediately after a release, so your concern (that something would be changed but not documented on the wiki) is pretty much taken care of already. —Dr Ishmael

14:21, 23 July 2013 (UTC)

This doesn’t work with categories, and never will. In the past, long ago, deletion tags were made using some “if template was applied three days ago, add to pending deletion category”. This however never worked because to make a page update its categories (or anything really), its cache needs to be refreshed completely. That only happens using a manual purge, or when an edit happens (the default cache expiration does not trigger category changes afaik).

Also, I don’t really see a need for such a category. You already have a list of changed skills on the update notes, even with a description that should give you an idea whether it needs to be changed. poke | talk 14:47, 23 July 2013 (UTC)

Nvm, that was just a proposal.

"Furthermore, I've noticed a small group of editors who routinely go through and update skill/trait pages immediately after a release, so your concern (that something would be changed but not documented on the wiki) is pretty much taken care of already." - adding category will remove the human factor, when someone can accidentally skip some items, or forget, or not being interested in the class he's not playing, or whatsoever. MalGalad 14:59, 23 July 2013 (UTC)

RFAs

→ moved from User talk:Tanetris#RFAs

As people may or may not know, since User:Pling's resignation earlier this month, I'm now the only bureaucrat. That means I'm the only person (besides certain Anet people) with the technical permissions to assign and remove user groups, e.g. to give or remove sysop/bcrat rights. While that isn't a huge short-term problem, as the workload there is certainly well within my means of dealing with, in the long-term, at least one more would be highly preferable, to cover if I should happen to go away for awhile, or if I become terribly corrupt, or whatever. So I'm putting out the call right now that I'd like to see the wiki community's ideas for another one (or more), in the form of RFAs. Whether it's a current sysop or just a regular user you think would be a good choice, this is what the RFA process is for. Bear in mind that the bcrat position involves a significant amount of discretion, requiring a good knowledge of the community, clear communication skills, a certain amount of flexibility, and in general the ability to make decisions that are fair and good for the community.

While on the subject, I would also like to say that our sysop list is pretty sparse these days. Again, I don't think the current workload is beyond our sysop team, mostly thanks to the wonders of AbuseFilter, and people who know my 'wiki politics' know I'm not in favor of any particular minimum (or maximum) number of sysops other than whatever number happen to be qualified, but I think it's a good time to remind people that if you know a user you think would make a great sysop, again, this is what RFAs are for. - Tanetris (talk) 20:11, 23 July 2013 (UTC)

There we go. poke | talk 20:29, 23 July 2013 (UTC)

Not to belittle yours, but I was hoping for a slightly larger turnout. - Tanetris (talk) 02:28, 25 July 2013 (UTC)

Perhaps it would be best to move this to the CommPortal... Aqua (talk) 03:11, 25 July 2013 (UTC)

At the time that I wrote this, the CommPortal's talk was already hosting two rather large discussions, so I didn't want it to get buried from those. It also contains a fair amount of my personal opinion, hence me putting it here and RFC'ing it. That said, given that the other two convesations on the CommPortal seem to have quieted down, and the low response rate, I believe I'll take your advice. - Tanetris (talk) 18:55, 26 July 2013 (UTC)

Champion rewards

So, with the champion rewards in the game, we get a huge mess on the wiki. So far, we tried to document the individual drops on the container item pages, but it turns out that the name and the rarity of the containers are not unique identifiers for them. I have a quick dump of the details of some of them in my sandbox. It turns out that there are many items that share the same name, the same rarity, and the same other details, but have a different id, possibly resulting in different contents.

I asked Stephane about this and after following back on the topic, he told me that they are eventually want to rename them so it gets a bit more specific when documenting it; but so far we aren’t there yet, resulting in 15 exotic Fallen Adventurer's Backpacks so far. He also told me that the difference between them is “champion-related” but he couldn’t specify further what differences there are. In the worst case, they simply don’t share the same contents at all, making it very inefficient to document it on the container articles (one never knows which container version the changes belong to).

As such I would say keep the container articles in a very general state (just really common contents, e.g. karma drips or knowledge scrolls; and a list of known champions that drop any of the containers). And then, on the champion pages we explicitely list the observed contents of the containers. I.e. make a “drops” section, list the container and then below the contents of that champion-specific container. E.g.

== Drops ==
* [[Elaborate Ritualist Bag]] (exotic)
** {{coin|400}} – {{coin|500}}
** 1 [[Drip of Liquid Karma]]
** 1 random weapon or armor of rarity masterwork or above
** 1-2 tier 4 or 5 [[crafting material]]

That way, we can cleanly document which champion drops what, without overwriting ourselves from different versions of a container. poke | talk 00:06, 8 August 2013 (UTC)

We can start a drop research article on champion loot bag instead of a research page on each loot bag to keep information together. It'll be more efficient than the spreadsheet/reddit thread.--Relyk ~ talk < 17:26, 8 August 2013 (UTC)

That’s a good way too. We just need to make sure that people find that. I’d suggest we put a big link on each container pages then. poke | talk 21:01, 8 August 2013 (UTC)

Agreed. I'll start working on some of the research. —Captain Combat

02:33, 9 August 2013 (UTC)

The bags probably identified by the race and effective level of the area the champion is in, while bags in upscaled zones and dungeons are identified by the race and level of the character. You can possibly spade the level range of each box using the upscaling in Crown Pavilion for those races.--Relyk ~ talk < 19:47, 10 August 2013 (UTC)

is it time to give Waypoints a linkable page or whatever?

→ moved from Guild Wars 2 Wiki talk:Requests for technical administration by way of Guild Wars 2 Wiki:Requests for comment

Now that Waypoints are API defined objects, is it time to think again about this? Something like a truncated POI page? --Claret (talk) 22:45, 8 August 2013 (UTC)

This should be on the CommPortal, it doesn't require anything technical. I'll wait until you move/repost it over there before responding, so I don't accidentally kick off a discussion on this page. —Dr Ishmael

22:54, 8 August 2013 (UTC)

OK here?

Sigh… --Claret (talk) 23:13, 8 August 2013 (UTC)

(Edit conflict) Now that we're in the right place... I think we should. A number of different editors have created waypoint pages at various times over the past year, so it's obviously something that a number of readers think we should have. —Dr Ishmael

23:16, 8 August 2013 (UTC)

I would like to see them as an infobox like a poi, there's not too much need on 99% of them for much more. But, having links, they can be referenced more easily. --Claret (talk) 23:31, 8 August 2013 (UTC)

Guess we will have pages with zone waypoints that stores link into subobjects. /sigh

"My body is ready". MalGalad 23:34, 8 August 2013 (UTC)

This seems like the same discussion that went on before. I much prefer having waypoint articles compared to putting subojects on the area pages, they are much easier to work with for everyone as articles. Poke has stated before that there isn't enough information, but we can come up with enough information to stick on it instead of just an infobox. The thing that comes to mind is notable locations from the waypoint since the location of something is often described in a direction from the waypoint.--Relyk ~ talk < 23:35, 8 August 2013 (UTC)

Wot he said. --Claret (talk) 23:37, 8 August 2013 (UTC)

@Mal: "zone waypoints that stores link into subobjects" I don't understand what you mean here. By creating pages for waypoints, we eliminate the need for subobjects on list-style pages. —Dr Ishmael

23:39, 8 August 2013 (UTC)

Whoever sets it up, bear in mind that Crown Pavilion Waypoint refers to both the one in Divinity's Reach and the one in the Crown Pavilion zone. Allow for that. --Claret (talk) 23:42, 8 August 2013 (UTC)

“but we can come up with enough information to stick on it instead of just an infobox” – Can we really? My point still stands (and forever will): Infoboxes are not a valid requirement to create an article for something. If we can say enough about waypoints that articles make sense, sure, go ahead. poke | talk 23:53, 8 August 2013 (UTC)

It was a thought. I don't know how the inner workings of the wiki go but it seemed to me that we could put the IDs in it, it's area and little else. I know we have them listed with ID elsewhere. Properties could be added to allow such things as {{area wps}}, a concept dear to my heart. But, I am far from sure, hence the request for comments. --Claret (talk) 23:57, 8 August 2013 (UTC)

@Ish, not far ago you stated that "waypoints is a special case" as well as achievements and "we won't implement the waypoint ids as properties on the chat link format subpages." (c) Relyk. So I assume this will be similar to achievements, a page with collection of waypoints and pages for some of them that need explanation. MalGalad 00:04, 9 August 2013 (UTC)

The two primary ways we would implement is (1) create waypoint articles and then make {{area waypoints}} on the area article or (2) create waypoint subobjects on the area article the waypoint is located in and redirect the waypoint name to the area article. It would look the same on the area article either way. It would be possible to treat waypoints as landmarks, a basic description of its location, an image of its location like a point of interest, and the location of other locations and events in the area relative to it. That may not be considered enough information compared to sticking it on the area article as there are maybe 1-2 waypoints in an area.

@Malgalad, the achievements were a special case because some achievements were trivial while other achievements require guides in lack of associated task like a jumping puzzle or minidungeon. We could justify a "guide/walkthrough" article for some achievements but not for others. For waypoints, it's a special case compared to other locations, where it's all-or-none on whether to have articles.--Relyk ~ talk < 00:19, 9 August 2013 (UTC)

Well... this is probably not a page to discuss it, but you're seriously wrong from logical side of view. Back to topic: I support your (2) proposal. MalGalad 00:26, 9 August 2013 (UTC)

(Reset indent) the other thing to consider is some waypoints get renamed and some are newly added all that trivia could go on a waypoint page but with that said all this info could go on the area pages as well because most of those are lacking in information imho.- Zesbeer 01:02, 9 August 2013 (UTC)

The last time we had this discussion, I pointed out that approximately half of the waypoints are named for a landmark that does not have a PoI - the majority of the Lionguard Havens fall under this. The other half share their name with the area or (primarily in Cursed Shore) a PoI. The unique waypoints could absorb the non-canonical landmark articles and basically look like a PoI article. The non-unique waypoints are where we'd still have a content problem, but if we go this route we would probably create them anyway for consistency. —Dr Ishmael

01:27, 9 August 2013 (UTC)

Cleanup of stub categories

→ moved from Guild Wars 2 Wiki:Admin noticeboard

For better organization and to allow people to work on the stub category I have made the template for stub work like {{section-stub}} However some cleanup needs to be done. Everything under Category:NPC_stubs needs the {{tl|NPC-stub}} changed to {{stub|npc}} then the Category:NPC_stubs category should be deleted. I was wondering if someone with a wiki bot could preform this action. Anzenketh (talk) 20:47, 18 August 2013 (UTC)

No. Rather change the existing templates so they work in the same way. For example make the NPC stub template use your changed stub template itself. That way existing usages of the template can stay, while the categorization is done using the new template.

Changing a temporary maintenance tag (which a stub is) on all pages is a highly redundant task (using a bot or not), instead the stubs should be resolved naturally instead.

Also, to suggest deletion of any page, apply the {{delete}} template. Note that non-empty categories won’t be deleted though. On a site note, please note that the category names do not follow our naming guidelines. “Category:NPC stubs” would be correct, while “Category:NPC Stubs” (uppercase S) is not. poke | talk 20:59, 18 August 2013 (UTC)

Due to naming guidelines were not followed I just solved this by fixing the issue with naming guidelines. Anzenketh (talk) 22:09, 18 August 2013 (UTC)

Thanks :) poke | talk 22:11, 18 August 2013 (UTC)

this should have been posted on the community portal talk not here fyi-

Zesbeer 23:07, 18 August 2013 (UTC)

Every Personal Story Mission In Video

→ moved from Guild Wars 2 Wiki talk:Practices and processes

So I was think of things to do with my 43 characters, and I decided to make a video series showing every personal story mission. The Videos would be linked so people could watch the videos in the same way that you would progress in the story. Someone suggested that it might be useful here for the wiki, and I thought that before starting I would see if it was something you wanted ect. (I Hope that this is the right place to put this) Blueblob0 (talk) 13:04, 6 September 2013 (UTC)

Our general practice regarding videos is that we do not link to any video directly (except for official ArenaNet videos) so that we are not seen to be promoting any specific channels/users. This was decided in response to edit wars on jumping puzzle pages where different users were indeed attempting to promote their own videos and suppress others'.

I think we should stick to that practice in this case, i.e. no direct links to videos for the specific story missions. On the other hand, I also think that adding a link to your channel or a playlist in the "External links" section on Personal storyline would be acceptable, since that's higher-level than a direct video link. But let's wait and see what other people think first, so we can get a consensus on this. —Dr Ishmael

15:11, 6 September 2013 (UTC)

I think a source rather then a external link would be warranted. I think we should have it still have the content be in text format. Anzenketh (talk) 15:29, 6 September 2013 (UTC)

The individual story mission pages will still have a text walkthrough, that's not really related to this issue. —Dr Ishmael

15:47, 6 September 2013 (UTC)

More of my comment is I think that it fits better as a source then a external link. External link I think of oh here is some more info on this. Mostly I am of the opinion that the game should be played to enjoy the story so I am actually on the fence if it should be linked to at all. Anzenketh (talk) 16:06, 6 September 2013 (UTC)

walkthrough for hearts

→ moved from Talk:Help Farmer Diah

I made an walkthrough how to do this for new playewrs, but it got reverted. I undone that, cause I would like to find consensus first and explain my meanings. Many pages on the wiki including the current one are just bullet lists, Lists are not very helpfull for new players, and people often prefer walkthroughs. In the first year we did a lot of documenting, but not much of making pages really helpfull. This is for 90% of the human players the first heart they encounter and therefor in my opinion even more important that there is a easy to follow guide. If people still disagree with me please discuss it here first. Ranique (talk) 12:02, 7 September 2013 (UTC)

"This is the first renown heart a player encounter when they choose to play as a human. The most effective way of filling this heart when there is no contributing event going on is to stomp Wurm mounds and kill the wurm hatchlings. Using the water bucket to water the corn or the bag of feed to feed the cows is a good way to learn bout the use of 'Environmental weapons' but takes more time.". My comments: Sorry but the English is poor - it may well not be your native language and I am surprised how well non-native English speakers deal with our quirky language. The walkthrough could, of course, be rewritten without a revert. I agree that there is an excessive use of bullets on the wiki, Having looked as a few others, I have come to the conclusion that the wiki's designers were obsessed with them. I really don't think that anyone who is going to play this game successfully is going to need a walkthrough at this level. By all means have a walkthrough where there are complex mechanics or other good reasons that would aid the user. --Claret (talk) 13:06, 7 September 2013 (UTC)

I know my english isn't perfect, and please correct me whenever you see it is done wrong. The issue I had with the revert is that it just deleted my addition. If you look at my contribs you can see that I have been going over all hearts, vista's and skillpoints in Queensdale. My plan is to next go through all dynamic events and after that to the next map. There is no rule for myself that I have to add a walkthrough. Where in my eyes the bullet list is enough, I leave it alone. I do agree that it is unlikely that new players who reach this heart will actually know bout the wiki, but as stated, I plan to go through all maps. My goal is to make the wiki more helpfull (while keeping the documentation in tact).Ranique (talk) 13:49, 7 September 2013 (UTC)

I really only think there's a handful of events and hearts that need prose to explain the mechanics. Help Albin Chronicler trade with the jotun tribe is an example of a heart that requires some description. And even that's overwritten.

That walkthrough basically boiled down to "mound stomping is fastest". Which even neglects killing the wurms, and if there's a lot of players in the area it might not be so fast, a high level player can one shot wurms from a distance, the events are faster, etc. It's a lot of words to say "do the things on the list". It's good for new players to see that hearts boil down to killing things, using bundle skills in the right place, talking to NPCs, etc. Hearts don't require careful pulls, aggro management, carefully constructed builds, dividing your forces or generally complex tactics at all. Manifold

17:07, 7 September 2013 (UTC)

Ok I wanted to expand the wiki from a bunch of bullet-lists to what a wiki should be. But it seems, that the concensus doesn't want that and doesn't welcome change. specially my request to wait for concensus on this being being ignored seems to me a sing that this wiki is bout elitism and not bout being open to people actually contributing. The line 'Notice something wrong, missing, or unsatisfactory? Feel free to edit pages yourself' seems empty words if it is reverted the way mine was.Ranique (talk) 17:37, 7 September 2013 (UTC)

Sorry, I am new so didn't watch the last review well enough. But point is that I think the way my first edit was reverted was not in line with the statement that everyone is invited to contribute. I do myself sometimes revert edits. but I try to only do it when it is simply wrong. I disagree with manifold. Again look at my edits from last night and I think that in only Queensdale there are a lot of pages that are better then the way they where. The jotun trading heart is a very important one, but the purpose of the wiki is in my opinion to offer help and clarification to those who are stuck. So just repeating what the infobox bout the heart is saying is not enough. Again I agree not many people will need help at this point. but if they do, I think this is the page they should find it.Ranique (talk) 17:47, 7 September 2013 (UTC)

There's a lot of specifics that a list of actions contains that the in-game heart description doesn't explain. I didn't revert all of your Queensdale changes so we'd have a chance to talk about it if necessary. I personally didn't think the walkthrough was helpful. Adding a block of text that adds nothing to a list didn't seem to be anything more than extra reading. Redundant text is not helpful to new players, either. I don't think anyone is going to get "stuck" because they can't understand a list. Please expand on why you think a paragraph of text is more helpful. Manifold

18:08, 7 September 2013 (UTC)

(Reset indent) The reason this wiki is primarily "a bunch of lists" is because we aren't Wikipedia. We are documenting a video game, and game mechanics are easily documented in list form. When there is lore to document, or a worthwhile walkthrough to write (dungeons/personal story/jumping puzzles), or basic game mechanics to explain, we use prose. Lots of it, sometimes (cf. Crafting). Outside of those cases, prose is just a longer way of saying something that can be presented concisely in a list. Lists are very easy both to write and to read, whereas prose has a lot more subjectivity in terms of style, voice, and perspective, and can be more difficult for some people (especially non-native speakers) to understand.

Hearts/tasks generally aren't complex enough to need a prose walkthrough. Chronicler Albin, as mentioned above, and the Ash Legion in Tawny Ridge are special cases where a prose explanation is necessary (the second one currently doesn't have a long walkthrough, but it needs one). Outside of that, a list of actions that contribute to the heart is sufficient. —Dr Ishmael

18:46, 7 September 2013 (UTC)

Weapon sets, unique weapons and named weapons

We don't really have a good way of categorizing and organizing weapons and armor. For someone browsing the wiki for these, focused on skins in most cases, it's really chaotic.

When browsing through weapons (which most people do for skins) I think the best way to divide them is as follows:

Weapon sets: Collections of weapons that share visual characteristics and name patterns. For example: Fractal weapons, Fused weapon skins.
Unique weapons: Weapons that have unique models and aren't part of any weapon. For example: Final Rest, Arachnophobia.
Named weapons: Renamed versions of weapons from the weapon sets or unique weapons categories, usually found in the Personal Story, karma vendors and karma vendor recipes. For example: Atlatl (Tribal weapons), Charr weapons (Steam weapons).

The same applies for armor.

Recently I reworked these pages: List of weapon sets, List of unique weapons, Armor set and List of unique armor to follow this pattern, and I think the result is much more better, cleaner and user-friendly than what we had before.

I would like to see the opinion of the rest of the wiki on this system, and get it somehow made official. I plan on improving it even more, and even adapt the category system to reflect this organization, but I would like some safety first. I don't want hours of done work and hours of future work vanish away.--Lon-ami (talk) 11:16, 10 September 2013 (UTC)

Named weapons was an alias for unique weapons because players complained about unique being a property. Making "named" refer to something else entirely is confusing and I don't understand what you mean by it. There's plenty to discuss on the list pages you've put massive amounts of work into, but main main problem is the quick reference tables when we have a table of contents, List of unique weapons being a giant gallery page, and List of unique armor being item icons for everything and containing mostly armor skins rather than unique armor.--Relyk ~ talk < 12:09, 10 September 2013 (UTC)

Oh yes, I forgot about it, but "Unique weapons" and "Named weapons" need new names (Standalone weapons and redundant weapons?), since both of them aren't clear enough. The point of the quick reference tables is to see easily if an equipment is available through different sources, and which weapon sets share models and skins.--Lon-ami (talk) 12:27, 10 September 2013 (UTC)

Yes, but the information is already there in the actual tables. I'd say make a single equipment quick reference page for all equipment and then people can navigate to a list of weapons or armor for more specific information.--Relyk ~ talk < 12:00, 11 September 2013 (UTC)

The problem I see is that there are acually two diffrent things mixed together. First is set weapons vs. non-set weapons. So is there a set of weapons which belongs together and if yes is the set complete? This is basiclly very strait forward and is the basis for the current wiki structure. Skin apearance has nothing to do with either of this.

The second thing is weapon model. Charr weapons are Charr weapons and Steam weapons are Steam weapons, but they have the same in-game appearance. It is surely an interesting thing to know, but this has nothing to do it the weapon is part of the set or not.

So I would propose to separate these completly. So we need a List of weapon sets and List of named weapons (Or non-set weapons) as well as a [[List of weapon models]] (or weapon appearances). I wouldn't call these weapon skins, beacause a weapon skin is a consumable.

The list of weapon models basiclly be an overview page for the gallery of <weapon> pages. Because seriously when I want a cool looking axe I will look in the gallery of axes and pick one of those. - Yandere

15:15, 11 September 2013 (UTC)

The weapon gallery pages are the lists of weapon models. The weapon galleries also have a weapon gallery nav. I don't think we need more than that?--Relyk ~ talk < 15:33, 11 September 2013 (UTC)

No they are not. A list of weapon models would clearly document which weapon sets use the same model. The galleries just show you all the images of all weapons of that type, they don't know or care which ones have the same appearance. —Dr Ishmael

16:51, 11 September 2013 (UTC)

I think it's clear as it is now, unless you want to navigate through the entire list, the quick reference table isn't good. People wanting to navigate through everything will use the quick one, the rest will use the separate, longer and cleaner tables below. It's just a matter of taste for the readers.

Charr weapons is an obvious recycle of steam weapons. It doesn't deserve to be there, it's redundant. What you're proposing as "list of weapon models" is done easier by moving "recycled" weapons to a "Named weapons" page. Want to see weapons that use steam weapon models with other names? Go there. There's no point at making a list of weapons with such amounts of redundancy, the list of weapons shouldn't repeat weapon sets with the same skins, unless it's not clear which is most original/primary. The main goal is to give each set of weapon models a single name, so the current chaotic situation where you can't call the same models by a single name is gone.--Lon-ami (talk) 20:44, 11 September 2013 (UTC)

The problem I have with these redundant weapons is that it is á priori not clear which weapon would be the default one and which one would be a redundant weapon. The both have the same model and there are both equal there is no reason to say that the one thing is redundant and the other isn't. Are Chaos Gun and Ilya redunant because they share their model with Lyss? Are Steam weapons redundant because they share the model with Charr weapons? You can't say that the one thing is the default and the other is not. Both have the same model. Either you list both pages or you list non.

There is actually one solution I can see. If all weapon models (except for the legendaries perhaps) are available in sPvP I can see that you could use the sPvP weapons as reference. sPvP doesn't reuse models because the only interesting thing a PvP weapon has is the weapon model. Same goes for armor and back items by the way. - Yandere

21:21, 11 September 2013 (UTC)

So we want a list of unique weapon models or a list of weapons that share the same model? The only reason to identify which weapons share the same model is if you wanted to grab the model easier to obtain for transmutation or offers the correct prefix. I don't see anything wrong with duplicates in the gallery since the gallery is doing what it's suppose to do and showing the appearance of the weapon. As far as Charr and Steam weapons, the only property they share is appearance.--Relyk ~ talk < 22:03, 11 September 2013 (UTC)

Steam and charr weapons are pretty obvious, in my opinion:

Steam: Cultural vendors, loot drops, WvW skins
Charr: Renown heart crafting recipe (Renown Heart vendors aren't famous for using good naming patterns for what they sell)

In the case of Ilya, Lyss and Chaos Gun, the precursor has less importance (no precursor has an unique model), so we would have 2 originals: Ilya and Lyss.--Lon-ami (talk) 22:11, 11 September 2013 (UTC)

Well, I stumbled across the Charr weapons first, because these are crafting recipes. So for me Steam weapons look like Charr weapons, not the other way around. And I would also say that the precursor is more important because it is more reknown, so Lyss and Ilya look like the Chaos Gun. That is excatly what I ment. There is no good reason to go with your version or my version. It is just an arbitrary preference.

Actually Rylyk made a good point. What is the problem in having dublicates in the list? - Yandere

00:04, 12 September 2013 (UTC)

The lists is aimed at models/skins, and we have a good amount of them already. Adding duplicated would make it a mess, that's why we should make a separate list for the duplicates, "Named weapons", where each original has its duplicates listed.

Also, I doubt you stumbled upon the crafting recipe first, because the basic blue weapon drops in all of Ascalon are steam weapons. Renown Heart stuff has proved inconsistent all the time, too, and I wouldn't take a single name from there. You can't compare some minor recipes with an established name ranging loot, cultural and WvW skins, it's ridiculous.

As for precursors being less important, if you take them as a group, some of them use duplicates from not only unique weapons, but weapon sets, too: Tooth of Frostfang (Corrupted weapons), which I think makes them second-class in regards of finding the "originals", effectively making precursors recycled versions of unique and set weapons.--Lon-ami (talk) 11:13, 12 September 2013 (UTC)

(Reset indent) Can't we agree that it's subjective? I support Yandere's idea of using the PvP names, since there is zero duplication on that side of the game. —Dr Ishmael

12:47, 12 September 2013 (UTC)

That's stupid, with all due respect. Have you even checked the PvP names? Sets with duplicate names, sets that have changed names after release, some even more than one time... Also, weapons sets with no conflicts (like dungeon weapons) have different names on PvP. Even worse, some PvP names have no versions on PvE with the same names. So yeah, an awful idea.--Lon-ami (talk) 12:53, 12 September 2013 (UTC)

Better than your idea, because you can't give a clean definition what a weapon set and what a named weapon is. Following your definition a Charr weapons and Steam weapons are both weapon sets, because they "share visual characteristics and name patterns" and they are both named weapons because they are "renamed versions of weapons from the weapon sets or unique weapons categories".

That is simple logic. You should realize that if you are the only one who can follow the definitions correctly (because they are by no means clear cut) it is not a good thing to include these in the wiki consensus, because you would be the only person, who can edit articles correctly according to the consensus. And that is not so so clever to be euphemistic. - Yandere

13:08, 12 September 2013 (UTC)

Charr and Steam weapons are both weapon sets - one is a crafted weapon set and one is a cultural weapon set - that use the same model/skin. I'm completely lost on whatever you people are trying to use the term "named weapons" for, I always thought that was to refer to weapons with unique names like Labrys (regardless of what model/skin they use). —Dr Ishmael

13:11, 12 September 2013 (UTC)

Yeah I agree with you, but the problem is that Lon-ami doesn't. His proposed categorization in is starting post is exclusive as far as I understood him. If he lists Charr weapons under named weapons (or redundant weapons as he later calls them) it would mean that Charr weapons wouldn't be weapon set. I think his idea is tho categorize everything which has not a unique skin under a this redundent weapon category because it would make it easier to find interesting skins in the remaining two categories. That is how I understood him (I can be completly wrong on this one). - Yandere

13:27, 12 September 2013 (UTC)

Named weapons would include both redudant unique weapons and redudant weapon sets. I think it was obvious from the example above. Re-explained:

List of weapons: Original weapon sets - Fractal weapons, Fused weapon skins, Steam weapons
List of unique weapons: Original standalone weapons - Meteorlogicus, Arachnophobia, Final Rest, Tsunami
List of named weapons: Weapon sets and standalone weapons with recycled model+skin - Tooth of Frostfang (Corrupted weapons axe), Charr weapons (Steam weapons set), Storm (Tsunami)

Clear now? List of weapon sets shouldn't have two differently-named sets if they share the same skin, unless it's a special case. In that page, one set should be one model+skin.--Lon-ami (talk) 16:48, 12 September 2013 (UTC)

Uh... not really. A list of weapon sets should list ALL weapon sets, regardless of the models used. A list of weapon models would list each model only once, but then it should also list which sets use that model in order to serve as a cross-reference. —Dr Ishmael

17:44, 12 September 2013 (UTC)

How is listing all weapon sets, ignoring model+skin redundancies useful? What would be that list for? Would a normal user find it useful? Because I don't think so. When someone comes here searching for a weapon, he comes searching either for stats: Equipment acquisition by stats or skins, and he wants to know which weapons share a common theme and which don't. Listing everything in a single page isn't user friendly at all, that's why I'm suggesting making 3 pages, so it isn't useless for visitors not interested on raw documentation.--Lon-ami (talk) 17:55, 12 September 2013 (UTC)

You are assuming too much about what readers want/expect, and you're entirely missing my point. I may be a very active editor and an admin, but I'm still a reader, and when I see a page titled "List of weapon sets," I expect it to list all weapon sets available in the game. I do not expect it to be limited in any way: it should fulfill the purpose that the title indicates. —Dr Ishmael

18:05, 12 September 2013 (UTC)

I am with Ish on this one. A list of weapon sets should include all weapon sets, a list of standalone weapons should include all standalone weapons. You can make a list of weapon models if you want to this should include all weapon models, and hopefully no or not to much dublicates. - Yandere

18:12, 12 September 2013 (UTC)

What's a weapon set, though? We don't have any definition for it.--Lon-ami (talk) 18:52, 12 September 2013 (UTC)

Buh? That's a dumb question. A set of weapons, one of each type, that share an appearance theme, stat levels, and acquisition method. Bronze weapons is the standard tier 1 crafted weapon set. Charr weapons is a special tier 1 crafted weapon set. Steam weapons (ignoring the loot version for now) is the tier 1 charr cultural weapon set. Charr and Steam weapons may share the same appearance, but they are distinct sets due to their different stat levels and acquisition methods. —Dr Ishmael

19:03, 12 September 2013 (UTC)

Basiclly what Ish said. I would like to add a few "strange sets". Light weapons and Makeshift weapons are also a set, but not a complete set, because not every weapon is represented once. And then we also have Legendaries and Precursor which are a set, because you have an umbrella term which brings them together.

That is why the discussion about the Phantasmal/Mist/Ectoplasm/Violett weapons was so controversial, because it was hard to find an umbrella term. That was basiclly solved by using the corresponding skill type as umbrella article.

Every weapon which can't be included in a set is a "standalone weapon". - Yandere

19:18, 12 September 2013 (UTC)

Oooh, I forgot - shared naming scheme is also a requirement in my definition of a weapon set. I wouldn't consider Phantasm/Conjure weapons to be weapon sets because a) they are far from complete and b) they have unique names; they're only related through their skill-themed appearances. —Dr Ishmael

19:49, 12 September 2013 (UTC)

Ok, it seems like we have a lot of criteria going around, and mixing and matching are being an issue. So, let's try to talk out the attributes and see how they should be grouped and defined.

Name (similar and uniquely named)
Model (shared or unique skin)
Acquisition (crafting, forge, quest, loot, from same vendor)
Mechanic (unique attribute)

So, looking at that, we have 3 ways of defining sets (similar name, similar model, acquisition), 2 of defining "doesn't fit"-sets (uniquely named, unique skin), and 1 way mechanically. Looks to me like we need 6 pages: List of sets by name, list of sets by appearance, list of sets by acquisition, list of (weapons) with distinct skins, list of distinctly named (weapons), list of unique (weapons).

So, Steam weapons would have an entry in name, appearance, and acquisition. For weapon sets that share a skin, either one just gets picked and all others refer to it, or each set just stands on its own. --JonTheMon (talk) 21:14, 12 September 2013 (UTC)

See? Not even you agree between each other, this needs real deep discussion. In my definition of weapon sets, I don't include "each of one type", and I include "unique model+skins not present in any other set". And the wiki has no official definition anywhere.

Also, I think a weapon set needs 2/3 of this to be a weapon set:

Name pattern
Visual appearance (They look the same)
Source (They come from the same place, vendor, etc)

Toy weapon skins lacks the name pattern, but has the other two. Conjure, phantasm and spirit weapons have the visual appearance, but no name pattern and inconsistent source, making them not a weapon set. Hall of Monuments weapon skins and legendaries have the source, but lack the name and the appearance. Light weapons is a set, yes, but it recycles skins from another one, which makes it a "named weapon set" instead.

Finally, have this clear: Model = 3d model without textures. Skin = textures that get put over the model. Some weapons share models, but not skin (like the ascended and super weapons), don't mistake these with "sets" that share model and skin.--Lon-ami (talk) 21:26, 12 September 2013 (UTC)

I don't understand why you are completely hung up on the unique model thing. You can have different weapon sets with the same model, that doesn't somehow make one of them not a weapon set just because it shares the model with another weapon set. —Dr Ishmael

21:32, 12 September 2013 (UTC)

It's my opinion. Charr weapons isn't a set for me because Steam weapons already exists. It's a duplicate, not an original, and should be labelled as such, not as a full weapon set. Original skins are a must to be a weapon set in my book, just like shared naming and one of each type is a must in yours.--Lon-ami (talk) 21:57, 12 September 2013 (UTC)

(Reset indent) I'd rather be more inclusive than to exclusive. Users are going to look for both Charr weapons and Steam weapons, so why not make it easy to find both? --JonTheMon (talk) 22:03, 12 September 2013 (UTC)

Well, if I'm sincere, looking at how armor sets work with this, it seems armor pieces of the same model+skins were included in the parent pages. In the case of Charr weapons, this would imply moving the entire Charr weapons page to Steam weapons. One model+skin, one page. For me, there's zero point at having two different pages with the same weapons, only with different names.--Lon-ami (talk) 22:06, 12 September 2013 (UTC)

The game itself identifies certain weapon sets like fused weapons by the prefix, which provides a baseline for weapon sets. It's also impossible to consider the two weapon sets the same because the weapons in each set would have to be the same, which they aren't.--Relyk ~ talk < 22:24, 12 September 2013 (UTC)

So, what about "Standalone weapons" for non-set non-repeated weapons? (Current "Unique weapons").--Lon-ami (talk) 19:24, 26 September 2013 (UTC)

templates: "item stat", "craft table row" + "prefix attributes".

original problem that brought about this diatribe

using {{Craft table row}} (which uses this template) dumps attribute properties such as "89 (Power)" on the base page. (e.g. querying "Destroyer Greatsword" for attributes gives "179 (Healing Power) + , 128 (Toughness) + , 128 (Condition Damage) + , 179 (Power) + , 128 (Precision) + , 9 (Critical Damage) + , 179 (Condition Damage) + , 128 (Power) + , 128 (Vitality) + , 179 (Toughness) + , 179 (Precision) + , 179 (Vitality)".. which is all the bonuses from all the prefix combinations. this messes up any queries.

I think {{prefix attributes}} is used in three places:

At the top within infoboxes of articles such as Twilight - this usage should produce semantic properties.
On variable attribute weapons (read: dungeons), in a separate section from the infobox such as on Nightmare Axe - this usage shouldn't imo produce semantic properties.
In "craft table row" in a table - this usage shouldn't produce any semantic properties on the base page. It records the prefix on each subobject anyway.

I would propose setting a variable at the start of a trinket/weapon infobox, e.g. {{#vardefine:inside infobox|+}}, and setting it to nothing, e.g. {{#vardefine:inside infobox}}, at the end of an infobox. I would, for each invocation of prefix attributes, check if that variable has been set, and if so, set SMW values, else don't set any SMW values. We could do this with separate if + switch statements in {{item stat}}.

Afterwards I would then propose setting subobjects for each each variation on "variable attribute" articles, and somehow replicating any properties set in the infobox for each subobject while not storing a generic version on that page. (e.g. not storing weapon stats for a Destroyer Greatsword without a prefix nor strength). this might get ugly. -Chieftain Alex 11:30, 16 September 2013 (UTC)

I had a thought, could we just use subobjects for weapons, and not store any info on the page at all? -Chieftain Alex

15:14, 16 September 2013 (UTC)

other

I can see two very similar templates that provide the images + numbers:

{{item stat}} - uses subtemplates from Category:Attribute icon templates. Annotates with SMW.
{{attribute}} - uses raw images and links, does not provide SMW annotation. (new, near duplicate, template from relyk 24hr ago)

Should we delete the second template + update the first with an option to not annotate with smw? -Chieftain Alex

11:30, 16 September 2013 (UTC)

I was planning to switch {{item stat}} over to {{attribute}} with setting properties. The reason I used raw code is because the individual attribute templates work off {{effect}}, which they shouldn't. I have the code done with User:Relyk/sandbox/attribute icon and [[User:Relyk/sandbox/item stat]] on the icon proposal, albeit different work in different places. On another note, we only need to store prefixes available for the weapon instead of the set of attribute bonus records.--Relyk ~ talk < 13:49, 16 September 2013 (UTC)

Red events

Scarlet's Minions Invade! and now Defeat Tequatl the Sunless are both large scale group events which basiclly needs the whole map to solve the event. They also use red markings on the map. Tequatl and Scarlet both use as an icon and new are the red cogs which mark the Hylek Turrets and the Megalaser. I called the red icons invasion icons because the only event that used it was called an invasion. Well I think it is clear that a few more events in this style will follow. The other dragons and world bosses will probably see some kind of revamp creating "raid" content for GW2.

So how do we call these things? Group and Meta events is both in use already. Raid events? - Yandere 12:10, 18 September 2013 (UTC)

World boss event icons. Red icons and circles have been used for certain world bosses like Shadow Behemoth since the start of the game. They also use red icons for dungeons, but we have been using normal icons on the dungeon pages.--Relyk ~ talk < 12:44, 18 September 2013 (UTC)

I actually never noticed that. I have a problem differentiating colors. orange/red, black/blue,etc. Only if you put them directly next to each other I can tell a diffrence. ^^

World boss events. Sounds fine by me. I would like to make an overview page were all these events are listed. - Yandere

16:40, 19 September 2013 (UTC)

As they don’t always involve a “boss”, maybe just “world events” or actually more correct “map events”? poke | talk 19:10, 19 September 2013 (UTC)

We want to use red icons for the dungeons as well if we add the icons. We can do {{event boss red}} next to {{event boss}}. I would prefer to use the approach I did with {{event flag}} and add a red parameter to switch the color of the icon.--Relyk ~ talk < 19:19, 19 September 2013 (UTC)

I like the idea with the red flag. - Yandere

21:37, 19 September 2013 (UTC)

Chat links in search

Welp. It’s not what I originally planned—and I will still complete that at some point to have this on the server-side—but hey, the demand was high… Anyway: If you search for something now, and it contains one or more chat links, the search will automatically recognize those chat links, decode them and try to find an article for it. If it cannot find an article, it will present the ID instead and ask the user to add the ID to the article of that thing he was linking to.

That whole thing looks like this and is pretty fancy I guess. As this was just a quick thing and probably lacks some functionality (or might even break :P), I’m more than open for suggestions on improving this. Have fun! poke | talk 15:41, 21 September 2013 (UTC)

OMG squee. Bug: it extracts the id for 0x04 links from the third and forth bytes rather than the second and third bytes (your example [&BCkEAAA=] links to waypoint 4 rather than 1065).

I've already written some code for decoding the flags data in item links (or rather, I wrote a library for decoding/encoding multiple types of links...), so we could use that to extract ids of transmuted skins and upgrade components too. Once I get around to posting it. -- Dagger (talk) 15:56, 21 September 2013 (UTC)

To note, this means you can do /wiki [&AgGLtgAA] to pretty much pull it up the wiki. :P--Relyk ~ talk < 16:02, 21 September 2013 (UTC)

Currently, searching for an item ID of crafted weapons/armor like [&AgFxtAAA] will return a result like Dredge Harpoon Gun#item3. The link works, but the title doesn't match the item they see in-game, and the anchor name looks odd in a search result. Can you do anything about this? Maybe pull ?Has canonical name for the display text? —Dr Ishmael

16:14, 21 September 2013 (UTC)

(edit conflict) Oh, you’re right, Dagger. Thanks and fixed :)

Regarding item upgrades etc.; This is something I won’t implement in this version but rather want the server-side version for. I have basic functionality for upgrades/transmutations already working in it, but I’d welcome if you would show me your library when you’re done with it. As it’s already been a while since I investigated on the item chat link format, I might be a bit outdated ;)

On a site note: Reddit’d and tweeted it.

Ish: I’ll see if I can get that from somewhere. poke | talk 16:17, 21 September 2013 (UTC)

And done! Canonical name is being used for the link text now :) poke | talk 16:30, 21 September 2013 (UTC)

Awesome. This deserves a sitenotice. —Dr Ishmael

16:38, 21 September 2013 (UTC)

Very nicely done :) --Fowk (talk) 18:20, 21 September 2013 (UTC)

I'd really love to have that for the german wiki too but /wiki is kinda broken for translations anyway... (i know that /wiki de:PAGENAME works) :o --Smiley™ de: user | talk 18:28, 21 September 2013 (UTC)

Some things don't work well.

http://wiki.guildwars2.com/wiki/?search=[%26AgE%2BAAAA][%26AgE%2FAAAA][%26AgFAAAAA]

These are chat links for the default town clothes, but they link to some random points of interest. -Sharkinu

17:05, 22 September 2013 (UTC)

That’s a problem we have because we share Property:Has game id across different types of articles. We will have to split that up into item/map/recipe/skill/trait ids. poke | talk 17:12, 22 September 2013 (UTC)

Poke, you already have separation for items/map links, adding Has type for map links and, e.g. Has item rarity for items into query should be trivial, isn't it? MalGalad 17:29, 22 September 2013 (UTC)

How does the chat link only pick up the id for a map id? It should pick up id for the town clothes as well. I thought that wasn't necessary since the chat link will contain the id type?--Relyk ~ talk < 18:38, 22 September 2013 (UTC)

I currently pick up anything that has Property:Has game id set to the id. And then I take the first. I’ll try using those additional properties to differ between the types, but in the long run, I probably want to split it up. poke | talk 18:57, 22 September 2013 (UTC)

~~You can't identify the type from the chat link?~~ It's the same problem for {{item type}}, so that can be changed at the same time.--Relyk ~ talk < 19:07, 22 September 2013 (UTC)

Hmm, maybe we should just add some “Property:Has object type” or something. poke | talk 19:15, 22 September 2013 (UTC)

We discussed this before :P--Relyk ~ talk < 20:15, 22 September 2013 (UTC)

Riiight, but we never got anywhere, did we? :P poke | talk 20:19, 22 September 2013 (UTC)

Because you haven't agreed to Has asset type. It's all your fault.--Relyk ~ talk < 21:30, 22 September 2013 (UTC)

You didn’t really provide any arguments for it :P And I think “asset” is a bad name. An item/skill/trait is not an asset (type).

Anyway Relyk, can you change Template:Dye infobox to use Template:Default item parameter internally? poke | talk 21:43, 22 September 2013 (UTC)

Sharkinu: Fixed! Thanks for reporting this and also thanks to Malgalad ;) poke | talk 21:55, 22 September 2013 (UTC)

Maybe Has page type as the infobox we use depends on the page. You have the ambiguity of item infoboxes being Item for a value if you don't define it by the equivalent of what infobox is used on the page. We need to know beyond it simply being an item besides for generating a chat link, which requires a switch statement; similar to Property:Has skin type to work on different infoboxes. Not hard to add to infobox :o--Relyk ~ talk < 22:14, 22 September 2013 (UTC)

Items are somewhat a special case; a lot other things are actually items: Weapons, armor, trinkets, dyes, … Those are all the things that are separately queries in {{Item type}}. Do we need this page/object/asset type separation for anything else than chat links? Because if not, we should probably just opt for the more clearer solution and use different properties for different IDs. I imagine that this will produce faster queries internally too if we have an actually unique key instead of having to check two properties to find the correct thing for an id. poke | talk 22:23, 22 September 2013 (UTC)

The problem with {{item type}}, you are querying to check if each property exists for the page, making 5 calls every time instead of 1. It became a problem because subproperties aren't working.--Relyk ~ talk < 20:15, 23 September 2013 (UTC)

Hardened Scales is [&B5BTAAA=] but search doesn't match any article. BryghtShadow (talk) 20:32, 24 September 2013 (UTC)

Effects weren’t indexed yet; fixed that. Thanks for the heads-up :) poke | talk 20:44, 24 September 2013 (UTC)

I'm sorry this is off-topic, but thank you guys for working on this so hard. For working on everything so hard, really. The wiki is used by everyone because it's so useful, and you guys make it so. Thanks! --RoyHarmon (talk) 12:18, 25 September 2013 (UTC)

That’s certainly not off-topic! Thanks for your kind words; we’re happy when people are happy about what we do :) poke | talk 17:27, 25 September 2013 (UTC)

(Reset indent) Another idea: what if add functionality to search linked items in the API, and add to the result text string, like:

 There is no article linked with this ID (100500) yet. Probably, you meant Item?

This will shorten the path to new articles... MalGalad 10:51, 30 September 2013 (UTC)

I have recently added IDs to all of our articles which exist in the API, so there shouldn’t be a non-recent item without an ID (except for some edge cases). Or do you mean having a red link there for creating the article? poke | talk 11:22, 30 September 2013 (UTC)

Yeah, a red link. That easily indicates if there's no item with such ID, or the ID just wasn't added. I do not insist this is necessary, but this is technically possible and can save a few seconds. MalGalad 11:33, 30 September 2013 (UTC)

Uh, poke, effects still don't appear to be matched in query... Besides Hardened Scales above, another is Carrying Antitoxin (search). --BryghtShadow (talk) 13:38, 22 December 2013 (UTC)

Basically Relyk broke it (quel suprise) with this edit to the effect infobox. While my revert has fixed the chat link search, it displays as "Carrying Antitoxin (skill)" rather than "Carrying Antitoxin (effect)" when you search. -Chieftain Alex

13:59, 22 December 2013 (UTC)

Effects are internally skills too, so they share the ID range making it not possible to differentiate between actual skills and effect when just looking at the ID. I’ll try to check for the effect context too and differentiate by that. poke | talk 15:50, 22 December 2013 (UTC)

The effect game context is now correctly supported and differentiated. poke | talk 17:58, 22 December 2013 (UTC)

Request for widget editorship

Since there's no other place for it, i'd like to request widget editor rights so that i can add and edit the API maps widget (demo) i created, polish (or even rewrite) it and possibly add some SMW related things i had in mind. Sadly i don't have much support from the german wiki community so that i stopped development but i still believe it is a must-have for the wikis and therefore i ask you for your help and support. --Smiley™ de: user | talk 19:56, 23 September 2013 (UTC)

trait-triggered skills

For reference: I have uploaded screenshots of all traits (in Heart of the Mists, naked) to my Google Drive. I have updated elementalist traits and User:Mora has updated mesmer traits, but if anyone wants to hit the other six profession while I sleep, go ahead.

So now that traits show the associated skill that they trigger, which isn't always the same as the standard skill, how do we document them? Let's gather some ideas. —Dr Ishmael 00:40, 16 October 2013 (UTC)

For first impression, identical to {{skill fact}} as {{trait fact}}. I don't like the semantic of "skill fact" used for skills on a trait template, although they are pretty much the same thing. Evasive Arcana and glyphs are special cases for attunements with multiple skill effects tied to one skill. Creating individual skill pages and having Glyph of Storms as the parent works. We don't have a similar structure for traits.--Relyk ~ talk < 03:25, 16 October 2013 (UTC)

It doesn't make sense to have two separate templates. Should we just rename it to {{fact}}? But that's off-topic - and unfortunately I don't understand what you're suggesting for the on-topic portion of your post. —Dr Ishmael

03:32, 16 October 2013 (UTC)

Thought that was one of things you were referring to, I guess no discussion is needed for trait effects. Not sure what you are referring to for trait-triggered skills, thought trait facts would address the trait-triggered skills apart from the special case for Evasive Arcana along with related traits and skills.--Relyk ~ talk < 04:11, 16 October 2013 (UTC)

I'm talking about the skills that traits trigger - in game, they are now shown above/below the trait tooltip. Example time: Lava Tomb triggers a Lava Font, but it's not the same as the standard Lava Font skill. I noted the details for the triggered version on Talk:Lava Tomb (I also did this for all other elementalist traits that trigger skills). So how do we document that special version of Lava Font? The answer is probably obvious, but I want to leave the floor open for ideas so I don't feel like I'm forcing my vision on the wiki. —Dr Ishmael

04:30, 16 October 2013 (UTC)

I see what they did with that. The trait skills would fall under skill infobox with the type being trait and the parent being the name of the trait. The information would ideally be on the trait page as navigating to another page for the skill triggered by the trait without trait information available isn't too useful.--Relyk ~ talk < 05:53, 16 October 2013 (UTC)

I actually wouldn’t really mind having its own article for them, i.e. “Lava Font (Lava Tomb)” in this case. But that might make it too hard to navigate… poke | talk 10:40, 16 October 2013 (UTC)

Although this is a new topic on the community portal, someone has gone and removed all the skill notes from all traits that trigger a skill. I find this makes it harder to understand what the traits do. It's not helpful to a new mesmer to read that Descent to Madness causes a Chaos Storm, since they won't necessarily know what that is. Isn't there some way a wiki can replicate relevant details on both articles? And until that happens, shouldn't we leave the current notes ? 75.37.22.43 05:00, 17 October 2013 (UTC)

Ishmael moved it to the talk pages and this only applies to the few traits that have triggered skills. It prevents edit warring for how it should be formatted. We haven't had the tooltips for over a year now, I don't anyone will mind referring to the game itself if they need information for now.--Relyk ~ talk < 05:37, 17 October 2013 (UTC)

A few ideas for the topic: like poke said, make a disambig version of the skill and have it name the trait as a parent. Have a sub-page of the skill and have it name the trait as a parent. Add the skill infobox on the trait page, but make sure it properly handles same-name skills. I'd go with 2 (to make it explicitly clear where the skill comes from), but that might have some parsing issues (we can handle disambig, can we handle sub-pages?). After 2, i'd imagine 1 would be the best. --JonTheMon (talk) 12:54, 17 October 2013 (UTC)

I’m usually not a fan of subpages, so if we make it have its own article, give it a proper name. poke | talk 15:00, 17 October 2013 (UTC)

(Edit conflict) Sorry, it probably was premature of me to remove that info, I just didn't want to have to make another pass through the traits later. As for ideas, I would go for a separate page with a "Skill Name (trait skill)" style of naming (this is similar to what Poke suggested, but with a generic qualifier rather than using the trait name as qualifier).

I'm not sure about the idea of subpages, as I think that would complicate navigation more than qualifiers do. And I really don't like the idea of dual infoboxes - documenting the skill on the trait's page. We tried that for a while on GuildWiki, documenting a consumable's effect on the item's page, but it didn't work out very well. —Dr Ishmael

15:06, 17 October 2013 (UTC)

icon template review

Icon
- {{skill icon}}
- {{trait icon}}
- {{effect icon}}
Icon + Wikilink
- {{skill}}
- {{trait}}
- {{effect}}

General

I know that an icon and wikilink is desired most of the time in lists, hence why our icon templates generate the wikilink by default. If we want the icon by itself, we have to add parameters like with {{effect}} or hardcode it. I suggest we have "<name> icon" refer to generating the icon itself, with the name alone generate the icon+wikilink. The difference would be the icon templates would be parameterized for size and link with defaults. The link templates do additional work with generating a wikilink and displaying information (game description) in the tooltip. It's worth the effort to have templates just for the icons for easy generation and I like a semantic like {{event}} used for a list of elements.

Effect

The effect template is currently implemented with additional parameters to display either the icon or the wikilink. This is unnecessary for the wikilink and our other icon templates don't allow generating the icon alone. We also implement all our Category:Effect icon templates off the template, which is infeasible because there are 1000s of effects. This hurts {{skill fact}} as it currently makes reference to individual templates for generating icons rather than a general template like you see with {{skill icon}}. Along with having 65 icon templates when we only need one. Individual templates are good for conditions and boons, but other icons usually only appear in tooltips.--Relyk ~ talk < 18:37, 27 October 2013 (UTC)

I think we could combine all of that into a single template. All skill/trait/effect icons are (or should be) annotated with Property:Has game icon, and all names are annotated with Property:Has canonical name, so the queries are identical across all of these. (The only difference is that skill icons currently get parsed through {{borderless}}, and I'm sure we can accommodate that in an omnibus template.) By default, the template would generate link + icon; we can use parameters like link only=y or icon only=y for generating icon or link by themselves (even though I don't see why you'd bother with a template if you're just making a link). —Dr Ishmael

19:19, 27 October 2013 (UTC)

I don't like the icon only parameter, I'd rather have an template explicitly for generating the icon. The icon template should allow resizing while the name templates stay at 20px. I want to display the game description in the tooltip when a wikilink is available (or the trait line for traits). Like I said, the link only parameter is useless because then you just want a wikilink. We can use {{Property:Has game context}} to change the behavior based on the page and a switch statement, but that will end up complicated. A general icon template is possible, but the effect template needs the stack parameter and skill/trait shouldn't have the parameter available.--Relyk ~ talk < 19:59, 27 October 2013 (UTC)

Use variables {{#vardefine:link only}}/{{#vardefine:icon only}} to set it for a single template. sod writing it out each time. -Chieftain Alex

23:41, 27 October 2013 (UTC)

You know that's a terrible idea right? :P--Relyk ~ talk < 01:53, 28 October 2013 (UTC)

"the effect template needs the stack parameter and skill/trait shouldn't have the parameter available" So? Does it really matter if an extra parameter is available? —Dr Ishmael

04:41, 28 October 2013 (UTC)

In regards to an icon template, no :3--Relyk ~ talk < 05:52, 28 October 2013 (UTC)

Skill histories?

I think it would be an awesome idea to bring over the skill history project from GWW. Thoughts? :D

Example

{{skill history}}
==[[Game updates/2013-10-15|October 15, 2013]]==
* Skill now applies 1 second of immobilized.
* Reduced vulnerability stacks from 10 to 5.
* Increased initiative cost from 3 to 4.

{{Skill infobox
| name = Body Shot
| icon = Body Shot.png
| description = Make your foe [[vulnerable]] with a body shot.
| variables = {{Skill infobox/effects|damage|168|coefficient=0.5}}{{Skill infobox/effects|vulnerability|3.25|stacks=5}}{{Skill infobox/effects|immobilized|1}}{{Skill infobox/effects|combo|projectile}}{{Skill infobox/effects|range|900}}
| initiative = 4
| activation = 0.5
| profession = thief
| slot = weapon
| mainhand = pistol
| weapon-slot = 2
}}
{{clear}}

== Original ==
{{Skill infobox
| name = Body Shot
| description = Make your foe [[vulnerable]] with a body shot.
| variables = {{Skill infobox/effects|damage|168|coefficient=0.5}}{{Skill infobox/effects|vulnerability|3|stacks=10}}{{Skill infobox/effects|combo|projectile}}{{Skill infobox/effects|range|900}}
| initiative = 3
| activation = 0.5
| profession = thief
| slot = weapon
| mainhand = pistol
| weapon-slot = 2
}}

—The preceding unsigned comment was added by Somohexual (talk • contribs) at 20:48, 28 October 2013 (UTC).

While the reasons in favor of a project like this are good and noble, the reality is that it would be very difficult, first of all, to create the groundwork of documenting every skill's history over the past year, and second, to maintain such a project for any significant length of time into the future. The GWW project looks to have started up in 2007, and yet in the 6 years since, (judging by the project's Progress report) they haven't completely documented any one profession. So even though there are far fewer profession skills in GW2, I'd have to say that this simply isn't a feasible goal for the wiki. —Dr Ishmael

21:52, 28 October 2013 (UTC)

This site pretty much lets you search for all the changes to a skill from game updates. I'm sure you can do something similar with DPL with our game updates. Not sure how much value it adds to the wiki though.--Relyk ~ talk < 22:25, 28 October 2013 (UTC)

Skill history was a great idea on gww. The history was interesting + sometimes suprising. Unfortunately it is immmensely long and tedious to work out all of the changes - although this is because you had to access older databases than gww to find the historic versions... which wouldn't be a problem on the gw2w. Same problem with getting a willing taskforce to crack it though. -Chieftain Alex

23:11, 28 October 2013 (UTC)

Tower of Nightmares

Tower of Nightmares (zone) → Tower of Nightmares
[[Tower of Nightmares (disambiguation)]]

?--Relyk ~ talk < 16:26, 14 November 2013 (UTC)

Yes, thank you. Rakuin (talk) 16:34, 14 November 2013 (UTC)

In prose: you're suggesting to move the article about the release to have a qualifier, then move the article about the zone to the unqualified name? Yes, I agree with that. —Dr Ishmael

16:57, 14 November 2013 (UTC)

DO NOT TOUCH

I found two strange digging machines in Bloodtide Coast that tell you to not to touch them, if you do you get knocked back. I guess these can be found in other areas too. Is this known thing or not? What are they? Upcoming updates stuff? Theories anyone? Rakuin (talk) 22:33, 27 November 2013 (UTC)

The forums are discussing them. They're new. Sometimes they push you back, other times they kill you, and all stages in between from what I gather. Seen a few around, not touched them because it says not to. --Claret (talk) 22:43, 27 November 2013 (UTC)

Your temperance amazes me. Hm, I got knocked back all three times I poked them. Need to poke them more. Rakuin (talk) 22:52, 27 November 2013 (UTC)

No poking please. poke | talk 23:40, 27 November 2013 (UTC)

Or peeking, I assume. --Claret (talk) 23:51, 27 November 2013 (UTC)

That would be a silly object name, I guess we can create the page with that though. [1]--Relyk ~ talk < 00:08, 28 November 2013 (UTC)

base ingredients

So I made a thing. MediaWiki doesn't allow recursive templates, so the code is a bit messy, but it works. Now, how should we use it? —Dr Ishmael 17:32, 20 December 2013 (UTC)

looks like fun. Some page where a user can enter an item name + then your template figures out all the subingredients (without saving) would be excellent.

I was thinking a form with no submit button would work, but forms don't preview wikicode templates ~~so my idea was poor.~~

Might be that a small widget could do the trick just nicely. -Chieftain Alex

17:41, 20 December 2013 (UTC)

How about Special:RunQuery/Base ingredients query (uses Form:Base ingredients query) Needs prettifying but seems to work! :) idk where we could link to that from or if that would be at all useful. -Chieftain Alex

18:05, 20 December 2013 (UTC)

I'd forgotten about RunQuery. That looks pretty good. —Dr Ishmael

18:44, 20 December 2013 (UTC)

I'd be much happer if I could get it to autocomplete values, or if I knew which properties it should match on. (has canonical name might work). Where else could we use this template (particularly static pages)? (could perhaps link to a runquery from inside recipe infoboxes..) -Chieftain Alex

18:47, 20 December 2013 (UTC)

That last bit was exactly what I was thinking. If there was a way to write a widget to expand it on-demand (rather than directly include it in every recipe box) (like Poke's widget for event status in the event infobox), I think that would be ideal. —Dr Ishmael

18:54, 20 December 2013 (UTC)

Is this not meant to be used as-is? Doesn't seem to return anything no matter what crafted item I search for. Vili 点

19:15, 20 December 2013 (UTC)

It's working fine for me - I just did Steel Axe Blade, 12 Slot Coarse Leather Pack, and Pile of Salt and Pepper.

@Alex: the autocomplete is working, but there's a limit to how many entries it can generate - start typing "Apothecary" and it should pop up some results. —Dr Ishmael

19:27, 20 December 2013 (UTC)

Neato. We could put it in the recipe box as a drop down menu, like "show full ingredient list". Psycho Robot (talk) 19:59, 20 December 2013 (UTC)

Reason for restricting it to recipes not from the Mystic Forge?--Relyk ~ talk < 23:12, 20 December 2013 (UTC)

Because someone went and put the material promotion recipes on pages like Iron Ingot, and we don't want to use those for base ingredient calculation. —Dr Ishmael

01:00, 21 December 2013 (UTC)

Its also less useful in general, because while someone could totally want to make a certain chef dish with lots of intermediate steps (like Rare Veggie Pizza), mystic forge recipes, more often than not, don't even have intermediate steps, or they are really simple such as refining ore into ingots into weapon parts. Still, that's an interesting question. What if you queried some ruby jewelry? It would go from ruby orb to 2 ruby crystals to 4 ruby shards. That's not necessarily desirable is it? Psycho Robot (talk) 01:04, 21 December 2013 (UTC)

Legendary weapons. Maybe restrict any recipes using Philosopher's Stone? Looking at the recipes requiring it, it's all base ingredients except for Eternity. That will filter out promotion. We can also make up the type (Mystic Forge recipes don't have a type afaik) for promotion to constrain it. For stuff like Ruby Orb, we can constrain it based on Refinement and Jeweler, everything else should be fine?--Relyk ~ talk < 01:16, 21 December 2013 (UTC)

Legendaries? No. This is intended for standard non-MF crafting, there's no reason to include MF recipes. —Dr Ishmael

01:29, 21 December 2013 (UTC)

The ingredient table on every legendary weapon page begs to differ.--Relyk ~ talk < 01:36, 21 December 2013 (UTC)

That table is much more useful (contains more information) than a simple list of base ingredients would be. Even if it's a bit ugly. —Dr Ishmael

02:05, 21 December 2013 (UTC)

An available (check)list of materials is useful and desirable for any item. The tables are not a reason to not have a simple list or the ability to generate the list. A separate template for MF recipes isn't necessary as far as I can tell.--Relyk ~ talk < 02:34, 21 December 2013 (UTC)

demo of why we limit to non-mystic forge. (promotion) -Chieftain Alex

09:13, 26 December 2013 (UTC)

I was under the impression that you didn't see categories for the mystic forge recipes (probably wrong on that), so idk if "type=Blood Promotion" is listed ingame or not. if it isn't, then we could make all the material promotion recipes use the same type + then we would be able to restrict it to sensible recipes with the exception of mystic clovers. (could use another parameter on {{recipe}} I suppose, such as don't-list-me-on-base-ingredients = y...) -Chieftain Alex

09:39, 26 December 2013 (UTC)

Nope, you're correct, there is absolutely zero metadata on MF recipes. All you have is the interface shown here, where it displays all MF-usable items from your inventory on the left, and four input slots on the right. Nothing at all to indicate what you're actually doing by placing items in the slots. I would really prefer that we stop making up stuff like recipe types for the MF. —Dr Ishmael

13:42, 26 December 2013 (UTC)

(Reset indent) Does anyone remember/know how to get the "query" parameter on #queryformlink to preload? (manual without examples ftl) Its something like:

Show the base ingredients

Except that doesn't preload... so its more like:

http://wiki.guildwars2.com/wiki/Special:RunQuery/Base_ingredients_query?Base_ingredients%5B1%5D=Loaf%20of%20Banana%20Bread&wpRunQuery=true
//wiki.guildwars2.com/index.php?title=Special:RunQuery/Base_ingredients_query&Base_ingredients%5B1%5D=Loaf%20of%20Banana%20Bread&wpRunQuery=true
//wiki.guildwars2.com/index.php?title=Special:RunQuery/Base_ingredients_query&Base_ingredients%5B1%5D%3DLoaf%20of%20Banana%20Bread&wpRunQuery=true
//wiki.guildwars2.com/index.php?title=Special:RunQuery/Base_ingredients_query&Base%20ingredients%5B1%5D%3DLoaf%20of%20Banana%20Bread&wpRunQuery=true

~~Probably #4 is my favourite...~~ Nope, broken, so 2:

<small><span class="plainlinks">[{{fullurl:Special:RunQuery/Base ingredients query|Base_ingredients%5B1%5D={{urlencode:{{{name|{{PAGENAME}}}}}|path}}&wpRunQuery=true}} Show the base ingredients]</span></small>

Show the base ingredients

I'm thinking bottom right of the {{recipe}} (if source =! mystic forge) -Chieftain Alex 18:59, 21 December 2013 (UTC)

3 and 4 don't seem to work. —Dr Ishmael

19:46, 21 December 2013 (UTC)

good spot. turns out everything in gw2 is not made with chilli peppers. I am disappoint. -Chieftain Alex

22:06, 21 December 2013 (UTC)

I've removed the default so it won't confuse you anymore. :P —Dr Ishmael

23:12, 21 December 2013 (UTC)

(Reset indent) So, it looks like the link works, and you can now get a list of base ingredients, but it's not fully working. For example, Berserker's Intricate Gossamer Insignia will send you to the query page, but you have to replace the ' in the name. --JonTheMon (talk) 21:56, 23 December 2013 (UTC)

Good point. Absurd expectations of pagename as usual. any other wierd punctuation in item names I should know about? -Chieftain Alex

22:02, 23 December 2013 (UTC)

And there I fixed it simultaneously on the other end. I'm pretty sure apostrophes are the only punctuation in item names that would be HTML-encoded. —Dr Ishmael

22:07, 23 December 2013 (UTC)

How to delete an image I uploaded accidentally?

How can I delete a wrong image that I uploaded accidentally? Sabsi talk 20:50, 23 December 2013 (UTC)

See Guild Wars 2 Wiki:Practices and processes, specifically the section on "Retention and deletion." In a nutshell: tag the page and an admin will delete it. —Dr Ishmael

20:59, 23 December 2013 (UTC)

stick {{delete|reason - oops accidental upload etc.|speedy}} at the top of the file page and it'll then magically appear on Guild Wars 2 Wiki:List of candidates for deletion, at which point an admin will see it. -Chieftain Alex

21:07, 23 December 2013 (UTC)

Done, thanks. :)

Sabsi talk 21:12, 23 December 2013 (UTC)

Glad we could be of help. (by the way, you know about the "move" option? this allows you to move pages and/or files to new titles (it leaves a redirect, which still has to be deleted, but its generally a good option to use in this case) -Chieftain Alex

21:20, 23 December 2013 (UTC)

Right, I realized I should have moved it right after I had already uploaded the one with the right name. I guess I just can't think clearly today, haha, sorry.

Sabsi talk 21:27, 23 December 2013 (UTC)

Don’t worry about it. The wiki software can be very overwhelming, so it’s normal to miss certain things when you’re not used to it. And accidentally reuploading is really not a problem :) poke | talk 13:11, 24 December 2013 (UTC)

Thank you. :)

Sabsi talk 11:32, 25 December 2013 (UTC)

Season vs Historical vs Temporary vs Future vs Partially Removed

There are a lot of items/NPCs (and even some zones) in the game that are here for a while and then removed. Documentation gets confusing as people add articles about things mined from the DAT file or mark as historical things that are in the game, but can no longer be acquired. I hope we can do something to make this easier on editors and readers alike, by distinguishing in some simple manner whether something is in the game now or not, whether it's likely to be in the game in the future.

I don't particular care how the wiki goes about this, but it seems to me that there are a couple of categories to distinguish and that some articles should be hidden from a lot of queries, e.g. if I'm looking up sources of Almonds/Bulk Almonds today, I shouldn't see the Zephyrite vendors. Categories might include

Seasonal (expected to return next time the "event" shows up again, e.g. weapons in Toypacalypse).
Temporary (only around as part of a specific storyline; could also include items only available as special offers).
Future (data mined or stuff found in public testing, but isn't yet in the game)
Non-renewable (sources were removed from the game, but not the item, e.g. Mystic Forge Conduits or Celestial recipes)

I imagine this could be handled with the various info boxes or templates, e.g. {{future content}} or {{temporary}}. I figure the coding experts can figure something out. My main point is: it could be easier on the reader to figure out if something is currently in the game or not and whether or not it will return. Thanks. – Tennessee Ernie Ford (TEF) 01:55, 9 January 2014 (UTC)

I have an intense dislike for the {{temporary}} tag because the article will mention such in the first line of the summary. It also looks like crap being plastered at the top of any Living World content. Same goes with recurring content, a tag on the top is identical to the phrase "during <event>" in the article summary. For limited/discontinued items, I somewhat organized Category:Discontinued items. Whether the items are obtainable will be mentioned in the "Acquisition" section. For historical content, we have Property:Is historical for filtering out content and it's already implemented in a few of our queries. Apart from being removed from the game, it's the fault of the article if someone reads the article and is disillusioned about the content being available in game.--Relyk ~ talk < 02:54, 10 January 2014 (UTC)

The problem is that people don't read the prose. That's why we created these temporary notices in the first place - people posting on the talk pages asking why they can't find the content anymore, even though it was stated in the prose. —Dr Ishmael

03:14, 10 January 2014 (UTC)

Seems like a vocal minority, I don't see people posting on every talk page of unavailable content.--Relyk ~ talk < 03:21, 10 January 2014 (UTC)

Then count me among the vocal minority, even if I haven't complained about it. When I load a page looking for some vendor or armor skin or consumable, I have three things I want to know: where can I get it, how, and what does it cost. That order isn't incidental, either: if an item is no longer available, or not until another special event, I want to know that now, before looking at another pixel of the page. Where do the silent majority start reading an article? At the top...the same place those tags go. Ugly? Certainly. Effective? Without question. If I need to go all the way to the "acquisition" section (never the first line of the prose) to figure out whether it's even possible to obtain something, then that article has already lost a good deal of my patience...I no longer care how pretty it is, either.

And I prefer getting my GW2 information off the wiki.

We probably all agree that suppressing currently (certainly forevermore) impossible recipes from queries is in everyone's best interest, though. Vili 点

10:28, 10 January 2014 (UTC)

It would be nice if there was a way to say "all these items are seasonal, all these other items are trade-only, all these items are here-for-now" and just turn them on and off as a whole. Maybe something with javascript and setting variables? But then, would that cause some SMW issues, since the query wouldn't actually know if a page was temporary or permanent? --JonTheMon (talk) 13:57, 10 January 2014 (UTC)

In all fairness, {{temporary}} was never designed to be plastered on every article (especially not item articles). It was more meant for the major parts of a living world update, e.g. a temporary activity would get it, but an instance that is limited to a single living story content anyway would not get it—instead, the infobox would show that. poke | talk 19:22, 10 January 2014 (UTC)

SMW has a specific function for recurring events. Probably implement it that way if it's something we want.--Relyk ~ talk < 19:42, 10 January 2014 (UTC)

(Reset indent) why not just add a temporary section to the info boxes so if its been removed it would say right there?- Zesbeer 02:00, 11 January 2014 (UTC)

SMW gallery caption

SMW galleries put visible anchor text in <img> title attribute because Property:Has caption. If we try to use plaintext such as by querying Property:Has canonical name, the gallerytext loses the link to the page. What to do? BryghtShadow (talk) 11:58, 7 February 2014 (UTC)

hmm you're talking about the hover text that appears on those galleries right. I don't think anyone has commented on it before, but yes I'd seen it. (as you say, its because "Has caption" is wikilinked as it is a page property).

we could a) not hover on such files and pretend it doesn't happen (:P) or b) do some kind of javascript regex magic to replace the title attribute in the second "a" element within "li.gallery.srf-overlay" elements (I don't do .js but I'm sure its possible) -Chieftain Alex

12:33, 7 February 2014 (UTC)

That's the captionproperty in the gallery result format. Looks like it's bugging with Property:Has caption being a page property and turning on the overlay`where you can't display links in hover text. Edit: Doesn't matter if it's a page property, brackets also cause it to break. It's either don't use overlay, don't use wikilinks, or leave it as is. I don't think it's an issue that needs to be addressed since the images have captions available.--Relyk ~ talk < 12:47, 7 February 2014 (UTC)

Living world changes

With the current living world we see a lot of changes considering locations off services like crafting stations and NPC's. I wondered if there is a policy on how to deal with this. We are confronted with changes but don't know if that is permanent. For example. Scornheart. We know he isn't in Lion's Arch any more since the town is under attack but he is replaced to Gendarran Fields. We don't know if thats a permanent relocation or that he will be moved back to a rebuilt Lion's Arch or that a new central hub will be created elsewhere, where he gets some place. So my idea would be to make a note bout his location during this living story and keep it as it is till now. But on other pages I see that changes are made as if it is permanent. Both are OK, but it might be good to agree on a policy here195.240.63.18 14:11, 21 February 2014 (UTC)

Since they're refugees, and they'll be moving around soon, right now it seems like it'd be best to follow the format of NPCs like Ellen Kiel who have already been moving around a lot. Psycho Robot (talk) 18:52, 21 February 2014 (UTC)

Template:Armor infobox is broken

Pages like Light Deep and Troubled Chestpiece, Light Blue Ice Shoulderguards or Bore Cloth Helm display Expression error: Unrecognised punctuation character "[". where the defense stat should be [2]. --91.96.120.198 14:58, 23 February 2014 (UTC)

The "type" is being defined twice. Remove the "| type = armor" and it works. --JonTheMon (talk) 15:31, 23 February 2014 (UTC)