Guild Wars 2 Wiki talk:Community portal/Archive 8

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.

Merging icon templates

Per #Line height, do we want to merge the redundant icon templates that would use the inline-icon class ishmael made? They're all doing the same thing except for some templates differing in default output, which isn't needed. Event icon would be a hassle due to it being implemented in other templates. The main advantage is having appropriate parameter names, but this isn't an issue for any of the templates except ones that overlap on the same icon anyways (i.e. event and map icons).--Relyk ~ talk > 16:35, 20 February 2013 (UTC)

If you want to have a general template for all icons, then make that and change the existing ones to simply use that. I.e. make it the way {{screenshot}} works: Simply calling {{ArenaNet image}} with predefined parameters. That way you don’t need to change any article, and you still have the benefit of a single implementation for everything.

Although I would argue that a single icon template for every possible icon would be a bit too much to maintain, so maybe just group them into categories (like map and event icons already are). poke | talk 18:39, 20 February 2013 (UTC)

That's what I would say if a single icon template were too cumbersome. A general template isn't worth it if it just sets the inline-icon, a nofloat, size, and link parameter would make it plausible and what we want. My main problem is special event icons, which get reused in-game for the map, events, and vendors and we get the duplication. The duplication is unavoidable due to the natural grouping into categories and the differences in switch statements.--Relyk ~ talk > 19:52, 20 February 2013 (UTC)

Use a single generic template for the surrounding formatting (so we can keep it consistent), but keep the event/dialogue/map/etc. split for picking the filename (so we don't have to edit anything). Like all the various attribute/effect templates using {{effect}}. In this case the existing templates would change to something like:

{{generic icon wrapper|icon={{#switch:{{{1}}}|...pick an icon...}}|nofloat={{#ifeq:{{{2|x}}}|nofloat|y|n}} }}

Where generic icon wrapper abstracts the CSS:

<span class="inline-icon" {{#ifeq:{{{nofloat|}}}|y|style="float:none; margin-right:0px !important"}}>{{{icon}}}</span>

—Dr Ishmael

20:10, 20 February 2013 (UTC)

That doesn’t really make it easier when you have to pass all those specific parameters through… poke | talk 20:17, 20 February 2013 (UTC)

Which templates are you thinking of merging? (there can't really be that many) -Chieftain Alex

21:15, 20 February 2013 (UTC)

{{map icon}}, {{event icon}}, {{vendor}}, {{crafter}}, {{gathering icon}}, {{trainer}}, and {{dialogue icon}} in some way.--Relyk ~ talk > 21:20, 20 February 2013 (UTC)

Merge all the templates.... Game icon could be a good name for the master template. - Yandere

22:09, 20 February 2013 (UTC)

This follows along the lines of the Has game id property for SMW discussed on User:Relyk#Has game id. In this case, we could have set a [[Has game icon::{{{icon}}}]] property as there is only one icon. It's constrained by he icon templates that implement the template. --Relyk ~ talk > 23:52, 20 February 2013 (UTC)

^ Last time I checked there were no real arguments for a single game id property. And I don’t see how that’s related to icons; I actually don’t see how the game icon property is related to displaying icons either.. But then again, I just woke up after way too less sleep… poke | talk 06:11, 21 February 2013 (UTC)

For making queries and output like {{event}}. I'm just pointing it out because we will be setting a icon property for multiple templates. Having an icon property for each category will be consistent with game id and how we implement {{skill icon}}, so it's very unlikely to have a generic icon property. Sorry if I'm confusing you lol.--Relyk ~ talk > 10:23, 21 February 2013 (UTC)

Your event template still uses the event icon template to render the icon, so this is completely tangential to the original issue of merging the icon templates to centralize the formatting. —Dr Ishmael

13:28, 21 February 2013 (UTC)

That's the point, it can have a game icon template render the icon instead. Or is that not up for consideration because we won't set the semantic property in the generic icon tempate either way?--Relyk ~ talk > 14:48, 21 February 2013 (UTC)

I'm still not sure why you're bringing SMW into this. We can't set a property for every place that we use these icon templates. We can do it for events, sure, because they have infoboxes, and we could probably do it for NPCs or objects (although the icon used in their infobox is the 64px texture, and the icon we display through the template is a 32px texture/20px tango). But what about map locations that don't have infoboxes or even their own articles like waypoints and vistas? Or dialogue?

My point is that in some cases, like events, we can use SMW to select the icon to be displayed, but that needs to be at a different level from the formatting that we're trying to centralize. —Dr Ishmael

15:19, 21 February 2013 (UTC)

Right, the icon templates are used outside the scope of infoboxes...--Relyk ~ talk > 16:06, 21 February 2013 (UTC)

Proposal

I made an example for all the templates at User:Relyk/icon, it doesn't implement the float parameter. This makes a simple visual for an "icon wrapper" template that all the icon templates can work off off. We will have a "Template:<type> icon" for each one. For most of the types, if an icon appears in one or more of the templates, I split it off. For example, we can have one icon template reference another as needed; the map icon template can reference the event icon template for any event icons that appear on the map. This avoids having to update multiple templates for the same icon. Nodes can be merged with map icon if we want or not, but I do prefer "node" or "node icon" over "gathering icon" for the semantic.

Ishmael suggested implementing similar to {{effect}}, where the parameter references a template. The list of icons isn't so long that it would be hard to manage, and then have existing templates refer off that. It makes it much easy to add icons than to have to create a whole new icon template if we need a new class of icons (like Living Story) before we can get icons. It's an issue I have with the effect template, where you have to use the misc to generate what you want (a dummy value for the parameter) or create an entire template for one effect. If people want to use the template parameter though, I'm fine with it.--Relyk ~ talk > 10:09, 12 April 2013 (UTC)

My mention of the effect template wasn't intended to suggest that we make a separate template for every possible icon. I was referring to its functionality, how it abstracts the formatting from the content of the effect icons - although I realize now that the effect template actually does this backwards from how I think it should be done. We would keep the map/vendor/event/dialogue/etc. templates as they are, but the formatting would removed to an icon-wrapper template to enforce uniformity. Basically, instead of {{map icon}} looking like {{#switch:blah blah pick an icon}}, it would look like {{icon wrapper|{{#switch:blah blah pick an icon}} }} and the {{icon wrapper}} template would have {{{1}}}.

Anyway, your template is still using class="inline-icon", which means it is still floated. —Dr Ishmael

12:57, 12 April 2013 (UTC)

If we have a class “inline-icon” anyway, can’t we just agree on using that everywhere and define it once so it works perfectly? Then we wouldn’t need an icon wrapper template, as we can just use ... directly. poke | talk 13:36, 13 April 2013 (UTC)

The main reason for the wrapper template, instead of just what poke said, is having the nofloat option as a parameter. We should be able to use any icon without floating although the most common use is having the icons float for bulleted lists and such, from what I've understood. We cannot use the default float on event icons as they need to be placed after the event bar. I like the idea of picking which types of icons float or don't float by default through the wrapper template. I get the idea of abstracting the formatting, but I wouldn't bother with only wrapping a class, it's more useful for abstracting the formatting code not in the class.--Relyk ~ talk > 14:17, 13 April 2013 (UTC)

A wrapper template won’t help you with such a float option though. If you want to make that accessible on the outside, you would still have to define that for every outer icon template. poke | talk 14:22, 13 April 2013 (UTC)

We have to define it anyways if we want all the icons to have an option to turn float on and off.--Relyk ~ talk > 14:39, 13 April 2013 (UTC)

Solved the floating problem - use an inline-block div instead of a span. Duh. I'll make this change to the map icon template and bot-revert all the "nofloat" usages.

Now, do we still want to combine all the icon templates into a monolith like Relyk is proposing? His current usage requires 2 parameters - icon category and icon name - which doesn't really make things any easier from the usability perspective. —Dr Ishmael

14:56, 13 April 2013 (UTC)

If we are going to have frontend templates (like {{map icon}}, {{event icon}}) anyway, I don’t see the need to abstract the icon definition into another hard-to-navigate super-template. Especially when all that template does it put the file inside a single span. It’s a lot easier to have it defined in the actual templates so that people can easily add new stuff there without understanding such a big template. poke | talk 15:01, 13 April 2013 (UTC)

You don't actually need the type parameter, I'm pretending those are the subtemplates. The only work the subtemplates do is give access to certain icons and set the link (maybe the tooltip). If we define all the possible icons available in a single template and provide a link parameter, then we can do the switch statement:

| skill challenge = {{icon wrapper|skill challenge|Dynamic event}} on {{event icon}}

| skill challenge = {{icon wrapper|skill challenge|Skill challenge}} on {{map icon}}

| skill challenge = {{icon wrapper|skill challenge|Skill point}} on {{dialogue icon}}

That makes it possible to use any image as a generic icon with the wrapper and implementing the icons in the appropriate subtemplates. Doing it that way isn't any harder than adding it to a subtemplate. You technically only have to add an icon to the wrapper if the file name has a qualifier or you want to change the link.--Relyk ~ talk > 06:30, 14 April 2013 (UTC)

Templates

User:Relyk/icon wrapper - Decided to include link and tooltip parameters rather than just being a wrapper for the class, making it very simple to implement on subsequent icon templates as you can see.
User:Relyk/sandbox/icon - Generic icon template that implements the icon wrapper for any article, using the pagename. This is similar to the approach we use on infoboxes and other places. It's not meant to be used on the specific icon templates.
- User:Relyk/sandbox/map icon
- User:Relyk/sandbox/event icon
- User:Relyk/sandbox/special event - Special event icons to be used across multiple icon templates.
- User:Relyk/sandbox/node - I feel these can be merged with map icon because they only appear on the map, there isn't any reason to separate them.
- User:Relyk/sandbox/service - Any service provided by an NPC. The goal is to have a single parameter on the NPC infobox that defines the "service(s)" an NPC provides and generate the appropriate icon. This will probably be an abstracted template that refers to categorical icon templates, otherwise it's the giant list of icons again:
  - Skill challenge - We can use our icon template here to generate the skill challenge. The more likely approach is a {{skill challenge}} template using the wrapper.
  - [[User:Relyk/sandbox/crafter]]
  - [[User:Relyk/sandbox/vendor]] - The only reason we wouldn't/can't merge the two is because crafter grabs the weaponsmith crafter tango and vendor grabs weaponsmith normal merchant icon.
  - [[User:Relyk/sandbox/trainer]] - Trainers are services but only differ with profession, .
- Attributes - The attribute icons each have their own template, but don't allow for displaying values like {{item stat}}. What we want is an {{attribute}} template to generate the icon and value if a parameter is supplied. It is possible to implement individual templates (there aren't that many attributes), but a general attribute template will simplify transferring over the item stat template because the parameters are the same.

It probably seems complicated, but not any more than what we do now and this would make icons much easier to use, add, and modify. Cheers :P--Relyk ~ talk > 18:24, 21 April 2013 (UTC)

So all you're trying to say is that you're using a template to format the items inside the switch statement on {{Map icon}} for example, to replace [[File:Complete heart (map icon).png|20px|link=Renown Heart]] with {{User:Relyk/icon wrapper|Event_Wintersday.png|Wintersday}}? nah.-Chieftain Alex

18:39, 21 April 2013 (UTC)

That's isn't all I'm saying, but thanks for the feedback...--Relyk ~ talk > 19:24, 21 April 2013 (UTC)

I think you could easily combine the icon wrapper and the generic icon template into a single one, making everything a bit simpler.. poke | talk 20:02, 21 April 2013 (UTC)

Couldn't you unify all of those templates into one master template by adding one parameter perhaps two? Then we could just start typing

Template:
  {{icon|category|iconInCategory|tooltip|SizeInPx}}
Examples:
  {{icon|map|sp}} would be the skill point icon
  {{icon|event|collect}} for our usual events
  {{icon|event|halloween}} or if you wanted to separate them {{icon|special event|halloween}}

so on and so forth?

Fresh Berry Smoothie 03:09, 22 April 2013 (UTC)

But there's no benefit in changing from {{map icon|sp}} to {{icon|map|sp}}. I think it would be more confusing, actually. —Dr Ishmael

03:48, 22 April 2013 (UTC)

^ That. With 100+ icons a master template would be terribly hard to maintain. poke | talk 07:46, 22 April 2013 (UTC)

The problem I have with icon is that most icons don't use the page article name and you spend a lot of time specifying the image and link either way, it would simplify the template otherwise. I made both for the proposal and that you can make the icon template from the wrapper.--Relyk ~ talk > 10:26, 22 April 2013 (UTC)

Icons and other stuff

I implemented User:Relyk/sandbox/icon without the wrapper and implemented it on templates that use icons. The semantics for making an icon changed. The first parameter is the article we want to link to. The image for the icon will then try to use the article name. The icon parameter is used to define the icon if it isn't generated automatically. For icons generated from infoboxes, such as traits, effects, and skill icons as we can then use the first parameter to grab Has game icon and pass it to the icon parameter. You can see this done with User:Relyk/sandbox/effect icon. I implemented the icon template on User:Relyk/sandbox/node and User:Relyk/sandbox/map icon. Most of the pages don't have an associated .png, pretty much pages without an infobox, which I suggest the semantic of using .png of article names for icons.

This also involves a rewrite of the effect template. The icon portion of the effect has been pushed to User:Relyk/sandbox/effect icon, only displays the icon and queries for Has game icon. User:Relyk/sandbox/effect displays the icon and wikilink, using the canonical name, which is identical to {{skill icon}}. We have this discrepancy for effects because they are the only icons that need the stacks parameter. That's why I won't bother changing "skill icon" to "skill" or "trait icon" to trait because we don't use those icons by themselves and they are widely used with that template name. Now that we have the icon by itself, we can generate icons for {{Skill fact}} without automatically generating the wikilink, which is how User:Relyk/sandbox/effect doesn't have all the extra parameters the {{effect}} does.

Attribute icons were implemented using the effect template. You can just as easily use the icon template as effect icon, except we don't have one. Attributes don't need stacks and don't have the game icon property. We also don't use the icons by themselves (although people love to use them inline, which is bad). So we make an User:Relyk/sandbox/attribute icon. The code for the template is generic, which we can use to implement additional attributes need it be. You will notice this embeds the value for the reason aforementioned, we do not use these inline. You will notice this is identical to {{item stat}}, except it doesn't set properties. This makes it quite simple to implement [[User:Relyk/sandbox/item stat]], which doesn't use individual attribute templates because we have a generic template to code off of. A major point of this is so we can display attributes without setting the properties and have a separate template do that in the infobox.--Relyk ~ talk > 22:41, 5 May 2013 (UTC)

User:Relyk/skill effect for a mockup of skill infobox/effects. User:Relyk/sandbox/effect displays the effect description by default in the hover description and No description found if not. This is because there will already be a wikilink to the name of the article. User:Relyk/sandbox/effect icon simply displays the name by default in the hover description. We can use the effect template for our our first examples, but as you can tell with generic icons such as Evade, we will go back to effect icon to generate the icon and link. By default, we're able to generate the effect icon separately from the wikilink.--Relyk ~ talk > 15:25, 10 May 2013 (UTC)

I think most people would hover over the link for a description, not the icon. Could it be on both? Or is it because some icons will be paired up with "custom" text next to it?

Fresh Berry Smoothie 20:47, 10 May 2013 (UTC)

MW doesn't let you modify the title on links. —Dr Ishmael

20:57, 10 May 2013 (UTC)

It seems as long as the specific icons followed the same format as icon, we can avoid coding against the generic icon template. We would still have the generic icon template to generate icons for stuff that isn't covered in implemented icon templates. But I would like all the icon templates to use the semantic of article name and then specifying the icon with the icon parameter; most icon templates do this already (the {{effect}} template).--Relyk ~ talk < 00:34, 19 May 2013 (UTC)

Proposed change for the skill table

Proposal:

The "Main hand only" and "Dual-wield" header for the tables should be changed to "One-handed", then combine the tables - weapons that does not provide skill 4 and 5 is clear enough that they can't be place in the off-hand weapon slot. This is consistent with the "offhand only" weapon skills where they only show skill 4 and 5 implying that the weapons can only be placed in the off-hand slot.
In general, tables with "main hand only" and "offhand only" headers are redundant. If the expectation is for the players to have the fundamental understanding of the skill bar and what skills belong to which hand, then we can combine the tables into one table with "one-handed" header. The skill slot number will take care of distinguishing the main hand, offhand, or both. Weapons with skill 1-3 are obviously main hand only, weapons with skills 4-5 are obviously offhand only, and weapons with skills 1-5 can be placed on either hands.
Special case - the elementalist profession cannot weapon swap and the skills are derived from their attunements. I proposed that instead of organizing their skills per weapons, rather have the weapons as a sub-header and the attunement as the main header.

Links:

- Related discussion: Talk:List of thief skills

- Proposed table setup: User:Sir_Vincent_III/sandbox

Reasoning: The proposal orignated with the confusion from the theif skills table. The information was misleading starting with the table categories. By having a "Dual-wield" header, it implies that to gain access to the weapon skill, the profession should wield the same weapons in both hand -- which is not the case. Also the term "dual wield" is exclusive to the Thief profession, thus seeing this term used on other profession implies that they too have access to dual wield skills -- again, not the case. So to achieve the goal of clear information, the table should be self-explanatory, thus if the weapon is a "two-handed", it should be found in two-handed table. We currently have that. But what we don't have is a weapon for "one-handed". Instead, what we have are tables with header "main hand only", "dual wield", and "off hand only" when in reality, they all can go under one header -- one-handed. The main hand/off hand classification is handled already by the skill slot location. If a weapon under "one-handed" has skills 4 and 5, the implication is obvious that it has to be in off hand slot. As for the elementalist, rather than having all different elemental attunement skills under a weapon type, it should be all weapon skills under each elemental attunement type (see my sandbox for clarification).

Thank you for your time. --Sir Vincent III 21:43, 28 February 2013 (UTC)

One compromise proposal was to switch the terminology from "dual-wield" to "main hand and off hand", leaving the structure mostly intact, but being more explicitly clear in what the table is describing. I personally prefer the current organization since it gives a good way to divide up skills beyond having a large table. As for the elementalist, absolutely not; you evaluate skills on a per-weapon basis since you can't swap once in combat, but you can still change attunements. --JonTheMon 22:14, 28 February 2013 (UTC)

I was thinking the exact same thing on elementalist - you don't normally want to compare skills of the same attunement on different weapons because you can't weapon swap; you want to compare skills on the same weapon of different attunements because you can switch attunement.

Changing the header gets no objection from me. I seem to remember I was uncertain of using that terminology in the first place, but no one else complained about it at the time, so it went in. —Dr Ishmael

22:41, 28 February 2013 (UTC)

Just to clarify my reasoning about the elementalist; it is mainly because of how the elementalist trait functions. An elementalist is mechanically forced to pick 2 elements to max, most cases only one element since it is also feasible to max Arcane. Since this is the case with elementalist, someone will go to wiki to determine which element to use and what weapon is the best for that element. Although you want to see how each skill changes when you switch attunement, that's not the reality in playing an elementalist. Often times, we pick a main elements and use the other elements only as supplements, thus the switching attunement is less important. If an elementalist is main Fire, the tables should accomodate that by classifying each skills by elements since other element would probably be less important since they are not traited that way. --Sir Vincent III 23:06, 28 February 2013 (UTC)

Many people including myself cycle attunements constantly.--Relyk ~ talk > 09:19, 1 March 2013 (UTC)

Just because you can’t trait all elements that does not mean you won’t continuously change your attunement. I actually know no good elementalist player who does not cycle through the attunements. Also the elementalist weapons decide over the play style. You don’t really choose a trait combination and then check which element/weapon is best for it. You rather pick a play style and then choose the fitting weapon and then trait to support that. poke | talk 12:18, 1 March 2013 (UTC)

As I have stated, my reason is not based on playstyle rather than gathering information and providing it to the readers and show what each element can provide the elementalist. My goal is to provide the information in a self-explanatory tables and let the player decide what playstyle they want to play with rather than implying in the table what playstyle they should play with. For those who argues that their playstyle involves constant attunement switching, we should keep in mind that the by doing so we are also shifting bonuses provided by our traits. Example, losing toughness provided by Earth to gain power provided by Fire. Plus never was it mentioned how these playstyle allocate points to traits. And I simply disagree that the "weapon decide over the play style" since there's only two things that matters; 1) what works 2) and what doesn't work. Those two things are decided by traits and elements. If, for example, we have 30 in Fire and 30 in Earth and 10 somewhere else, it doesn't really matter what weapon we use. So I simply cannot agree with the idea that the elementalist picks a weapon first before traits and elements -- some weapon just don't work. --Sir Vincent III 22:18, 1 March 2013 (UTC)

Back to this, should we change "dual-wield" on the pages to "main hand & off hand"? --JonTheMon 14:14, 21 March 2013 (UTC)

Eh, why not. —Dr Ishmael

15:31, 21 March 2013 (UTC)

Er, is it "Main- and off-hand" or "Main hand and offhand" or "Main and offhand"? --JonTheMon 15:43, 21 March 2013 (UTC)

Fudge, I don't know. I thought main-hand / off-hand where the proper forms, so main- and off-hand would be the way to combine them. Am I wrong on that? —Dr Ishmael

15:51, 21 March 2013 (UTC)

The current standard is "main- and off-hand weapons" (for the 1-2-3 & 4-5 skills) and "main and off hand" (for the right & left hands of the character). "Offhand" isn't wrong, but it looks odd to too many people. Don't forget to chance GWW:FORMAT if you change the agreed-upon style. 75.37.17.240 16:02, 21 March 2013 (UTC)

Guess I should fix the other headers to match that, too. Thanks. —Dr Ishmael

16:14, 21 March 2013 (UTC)

Proposed Addition of Skill-Specific Coefficients to Skill Pages

Heya all, so or a while I've wanted to be able to see the skill-specific Coefficient on the page for the skills themselves, so I thought "Hey, how about I do it instead of waiting around for it to be done :D" I'm kind of new to the wiki so at first I put a post up on Reddit about it to see if people would be interested, and since they are I started talking about it on my talk page. Then Dr Ishmael suggested that I move the discussion here :). So I was thinking we should add something along the lines of these -->

For skills that hit once

Skill-Specific Coefficient: 0.8

For skills with multiple hits

I wasn't sure which looked the best, so here's a few that Fresh Berry Smoothie, some folks on reddit, and I have come up with

Skill-Specific Coefficient (9x): 0.33

Skill-Specific Coefficient: 0.33 (x9) Total: 2.97

Skill-Specific Coefficient (9x): 0.33 Total: 2.97

Skill-Specific Coefficient (9x): 0.33 ⇒ 2.97

What do you think? I set it up so when you click the link it sends you to the damage page so you can see what the skill specific is used for, and where it is in the damage calculation. I think it would be a useful number to be able to know. With experience from browsing the LoL wiki and seeing the AD or AP ratios on an ability which helped me better gauge the skills effect, I think it would be useful here as well, since I find the damage portion of the tooltips to be kind of not so helpful, what with it being average damage against a 2600 armor target. As well as in a number of situation some skills tooltip scale with power, while the skills damage actually doesn't (a la' arcane blast)

So yeah, that's that. I know the grammar in some of that is pretty bad sorry ^^; Tell me what you think about it! Do you think we should add it or no? Thanks for your time. Habar414 02:02, 1 March 2013 (UTC)

We also need to list a coefficient for healing skills, right now the formula is added in notes. My suggestion is adding a coefficient parameter and displaying the coefficient in grey like with conditions: User:Relyk/sandbox/damage.--Relyk ~ talk > 03:20, 1 March 2013 (UTC)

I was going to suggest the same thing, Relyk. I support this idea. —Dr Ishmael

03:54, 1 March 2013 (UTC)

I like the way you think Relyk. However, how about attacks that do multiple hits? Yours shows the overall, but not all hits are necessarily going to hit the enemy. That is why I like to know what the "individual" coefficient is as well as the overall. However if we had to choose one it makes more intuitive sense to me to use the total. It is a simple matter of dividing by the number of attacks in my head to figure out the individual.

Fresh Berry Smoothie 04:32, 1 March 2013 (UTC)

Dividing by something like 0.3 isn't easy for everyone to do in their head, but I think we can safely assume that absolutely everyone reading the wiki has a calculator application near at hand (there's one bundled in every OS I know of, anyway). —Dr Ishmael

05:05, 1 March 2013 (UTC)

Okay I can't really do that in my head either, but you get what I mean :P In either case, the simple solution is as Relyk has pointed out. If anyone would like more information (i.e. single hit in a multiple hit coefficient) I feel they may be in the minority and would of course have access to a calculator to figure it out. I'm excited to see this change! Thank you Habar

Fresh Berry Smoothie 05:11, 1 March 2013 (UTC)

Dividing by .3? I don't see why you would be dividing, since it's multiplied with power and weapon strength. It could be seen as weapon strength * 30% of power/armor no? Perhaps I just don't see what you meant. I love that idea rylek! That looks great. My only issue is that at that point wouldn't the skill description differ from that in the game? Is that bad? o-o; (new to this whole helping on the wiki thing) Also, do you think it might confuse people who don't know what it is? Perhaps there's a way we can explain what it is better to people looking at the skill..hmm...

Last thing, so I'm not sure how to figure out the coeficient for some traits that deal damage since the damage can vary and there is no tooltip to rely on. I currently use this --> skill coefficient=(damage*armor)/(Weapon Strength*power) to find the coefficient. I dont know the "weapon strength* of the skills the traits use. Utility skills are also an issue because of this, but they have tooltips, so it's not so bad. Any ideas on how to figure these out? Habar414 06:17, 1 March 2013 (UTC)

We can stray from how the information is presented in-game. This is certainly a case where we should, considering how unhelpful the tooltip is. I made wiki tables out of the excel sheet from that reddit thread: User:Relyk/sandbox/coefficient.--Relyk ~ talk > 07:28, 1 March 2013 (UTC)

Should we have separate coefficients for damage and healing? I know the idea of a single "coefficient" parameter was thrown around, but is that a bit too restrictive? --JonTheMon 14:18, 1 March 2013 (UTC)

Each skill fact will be stored as a #subobject of the skill page, which will identify itself with a fact type. I don't think anyone would ever be interested in the coefficient alone, so queries should always select by fact type in any case, which means there's no need to separate the coefficients. —Dr Ishmael

15:12, 1 March 2013 (UTC)

Since I really don't know much about wiki code I'll just working on getting all the coefficients and making sure they're correct :D I'm really glad folks were into this idea! (Edit: Forgot to sign)Habar414 05:21, 2 March 2013 (UTC)

It's something that's been brought up multiple times, but always faltered because no one wanted to take the time to do the research. Now that someone else has done most of it (c'mon thief and engineer!), adding it to the wiki is just a matter of design and code. —Dr Ishmael

05:41, 2 March 2013 (UTC)

My results for thief, linked on the coefficient page: Thief skill spreadsheet.--Relyk ~ talk > 06:45, 2 March 2013 (UTC)

That looks way more correct. Thanks Relyk! Good job :)

Fresh Berry Smoothie 12:56, 2 March 2013 (UTC)

Alrighty, so I'm ready to start adding some of the coefficients any time, but if we want to use Relyc's idea for showing the coefficient as a grayed out number after the skill how do we go about setting that up?

Added it to the template. Add a coefficient parameter, such as {{skill infobox/effects|damage|strikes=9|coefficient=x}}--Relyk ~ talk > 02:29, 4 March 2013 (UTC)

i'm late to party but don't think you should worry about "adding up" coeff for multi hits, it depends. game lists total amount if the x# is infront of the : however the question is if the people who tested the coeff for both kind of multi hit skills on the final damage or the single hit? if THEY (researchers) did documentation based on literal single hits, then yes wiki side listings should do the "add up" or sum of coeff to bridge findings to in-game listing (unless they already did that too). healing skills thankfully have less of an issue as they list total or per without notification of multiple applications in a single go (although anet should update as far as skills like ether renewal or healing breeze is concerned).67.233.98.18 18:22, 15 March 2013 (UTC)

Each individual hit in multiple hit attacks deals an equal amount of damage; the damage is predetermined upon activation. It doesn't matter if you check individual hits or take the total damage and divide it by the number of strikes, as long as you don't get critical hits.--Relyk ~ talk > 22:13, 15 March 2013 (UTC)

yes thats understood already. this isn't about what skill does as that has already been proven, which btw thank you for correcting (tests were finding single hits strictly it seems from your links). the question at beginning of this topic (before my post) was if for the multi hitting skill, we list the total's co-eff (sum of co-eff) or just a single hit out of the many. the complication: the game lists its tool tip damage as end result, so should the co-eff do so too? 67.233.98.18 22:45, 15 March 2013 (UTC)

Ah we have the total damage value as a parameter instead of deriving it from the product of the base damage value and number of strikes. The point was for skills like Unload, which display the base damage. I agree we can leave the coefficient alone. We should be using base damage as the parameter value instead of the total damage, since the total damage can be derived from that.--Relyk ~ talk > 23:24, 15 March 2013 (UTC)

wait, did we both go backwards on ourselves then? or a full circle... anyways that specific skill, unload, is perfectly fine. it lists base damage already and doesn't total itself up like Death Blossom where in-game lists its damage as a total but indicates it is from multiple hits. this is where this entire talk second was supposed to be talking about for trying to display the coeff's. at this point i'm a loss of what to say though, so sorry. 67.233.98.18 01:44, 16 March 2013 (UTC)

The displayed coefficient should correspond to the displayed damage. Whether that means the input should be the total damage/coefficient or the single-hit damage/coefficient will be determined by the template implementation, which currently favors the total. —Dr Ishmael

01:57, 16 March 2013 (UTC)

Unload is a special case, almost all skills follow the #x hits format. It's really not a problem if we list the product, you can derive the base damage and base coefficient by dividing both by the number of hits. But for the ease of calculations for readers, we can either show the total damage and base coefficient or the base damage and the number of strikes times the coefficient. Since the game shows total damage, we should present it that way. We could totally just show base damage and base coefficient as opposed to the tooltip.--Relyk ~ talk > 01:59, 16 March 2013 (UTC)

not to sound like a troll or anything, but it seems you guys answered your own question and a little more. guess we have work to do to complete this project. 67.233.98.18 05:16, 16 March 2013 (UTC)

relatedly... did i format/organize healing power descriptions poorly? 67.233.98.18 05:20, 16 March 2013 (UTC)

Okay, so just to be sure since I'm starting to add these things to pages on pages that total up the damage in the skill description, like Rapid Fire, we do something like this

Damage (10x): 1,320 (3.7)^?

Combo Finisher: Physical Projectile

Range: 1,200

You're the only one asking questions, so it's all good.--Relyk ~ talk > 03:44, 17 March 2013 (UTC)

And for skills like Unload We do it like this

Damage: 101 (0.3)^?

Number of shots: 8

Combo Finisher: Physical Projectile

Range: 900

I'll be doing it like this for now, if you guys don't like it I'll be happy to swtich it to whatever you guys want :) Habar414 03:32, 17 March 2013 (UTC)

The coefficient parameter is the actual skill coefficient, the template can do any multiplication if we want.--Relyk ~ talk > 03:42, 17 March 2013 (UTC)

Okay, that's good to know, thanks Relyk. Another note, while I was putting up the ranger healing skill coefficients they already had notes about how much they healed for. I removed the note after adding the coefficient to the page, but it felt like it was too vague for people to understand easily. For heal skills do you think this would be an acceptable format?

Healing: 6,520 (+ 1.0 x Healing Power)^?

I figure this way it's more descriptive on what the numbers actually mean. I think it's possible to do this with heal skills since they have a more concrete formula, rather than damaging skill tooltips which rely on a few different things. Habar414 09:28, 17 March 2013 (UTC)

i like it, but what should we do about trait specific heals? 67.233.98.18 09:34, 17 March 2013 (UTC)

I'd like to use the template that healing skills use and plop it in the notes section of traits that heal. It would add some consistency to the way different sources of healing look on the wiki. P.S. Remember to sign your comments by ending your posts with 4 ~'s :D Habar414 09:40, 17 March 2013 (UTC)

I came across another interesting issue when adding some stuff to pages. So, do we want the skill description to reflect the skill's actual effect or to reflect what the tooltip shows in game? I'm curious because with some skills, like Healing Signet, the amount healed does not match the amount listed on the tooltip, and some skills, like Mercy Shot the tooltip shows an incorrect damage value based on an false skill coefficient. How do we show this? Have the coefficient be correct and not that the listed damage is wrong in a bug note at the bottom? Or do we fix the damage/healing and add that to the bug note as well? Or do we have the coefficient match the tooltip decription and note that at the bottom instead above the bug note? Thanks for your input. *EDIT* So, two more things. If there is a by lvl formula of the damage or healing on a skill do we leave it there in the notes section? Is that something we want to figure out and have on all skill pages? When we list the healing on traits should we be sure to mention that these are then numbers for when the player is level 80? As in "At level 80 this trait heals for -> (skillbox healing/damage thing.)"Habar414 11:04, 17 March 2013 (UTC)

I think in the first game's wiki they would put a "Note" or something to that effect at the bottom saying "Yo, what we wrote up top isn't exactly true....". Something like that could be done, but I would suggest that if it is incorrect that instead we have some type of flag at the top, kind of like we do for pages without documentation or "possibly false info", so that people are more readily aware that what's written below isn't the holy truth.

Fresh Berry Smoothie 13:11, 17 March 2013 (UTC)

The way you did healing looks ugly. I can put something in the template to explain it so we can remove all that extra text. —Dr Ishmael

14:11, 17 March 2013 (UTC)

Alrighty, sounds like a plan Dr.. I saw the little "?" mid edit and i was very confused, then I figured someone was doing something with the template so I checked here. I'll go back through and change the healing skills I edited back to the normal coefficient style. Habar414 14:32, 17 March 2013 (UTC)

Does the single question mark seem sufficient, or should we use something longer? Per your talk page, you didn't realize what it did for a while, so I want to make sure it's obvious enough for everyone else. —Dr Ishmael

14:48, 17 March 2013 (UTC)

Hmm, good point. Well, when I initially moused over it nothing happened, it was only after 2-3 seconds that the box shoed up. Is this just because of server delay or is there a built in timer on when the box shows up? Can we have te box show up immediately when moused over? Edit: clarification.Habar414 14:58, 17 March 2013 (UTC)

That delay is determined by your browser. For me in Chrome it pops up almost instantly, but I don't think it can be configured. In Firefox it's defined by the configuration setting ui.tooltipDelay. I don't know about IE. —Dr Ishmael

15:11, 17 March 2013 (UTC)

Assassin

There is a page called Assassin. There's a suggestion that it be moved to a new page, professional assassin to reflect the in game name of the achievement it refers to. There is a long discussion page also stretching way back.

I can't move it to there and indeed wonder if it's needed there. The Professional Assassin achievement is one of the PvP Conqueror set and the members of the set do not have individual pages.

The reason I ask is that there is a NPC type called assassin, part of the Voices From the Past storyline and I was intending to add them. The link on the storyline page goes to the "wrong" page.

Not sure if this belongs here but…

You would make a Professional Assassin page for the achievement. Assassin would be the correct place for the NPC article you mentioned.--Relyk ~ talk > 14:14, 2 March 2013 (UTC)

Yes, but I am not provided with a "move" option AND I question if there's a need for Professional Assassin as none of the items in the achievement group has a page. If you look at the content of the page, there's nothing of use there, IMHO, and the discussion page is of little use. Claret 14:18, 2 March 2013 (UTC)

The Professional Assassin page can just redirect to PvP Conqueror. You can wipe the Assassin page itself, no moving necessary.--Relyk ~ talk > 14:41, 2 March 2013 (UTC)

I see you have done it, I presume you have done the archiving as I have no idea how to. Claret 14:54, 2 March 2013 (UTC)

All done, thanks to you. Claret 15:23, 2 March 2013 (UTC)

Guild-related articles

could use its own color theme for class=" table" instead of mech1, especially with guild missions out. I also have a long-standing issue of not liking that all the guild upgrades are stuck on Influence, in a section on the Guild article called "Rewards". Can we give each of the upgrade categories its own page and have the guild and influences pages refer to them?--Relyk ~ talk > 22:49, 3 March 2013 (UTC)

Armor pages and galleries

Could I direct your attention to Guild Wars 2 Wiki talk:Armor formatting? (Older discussion at Talk:Armor#Gallery pages.) It includes a redesign of armour pages, creation of galleries, and cleanup of file names. Examples at Ascalonian Catacombs armor, Ascalonian Catacombs armor/Light (one gallery version) and Ascalonian Catacombs armor/Medium (another version).

More input would be welcome. pling 22:20, 7 March 2013 (UTC)

How come there aren't areas where people can copy paste the in game chat code to preview them? I know that one could actually visit this vendor, but I meant for us lazies out there ;) Could we have another section below or perhaps incorporate in INTO the table? I would be very willing to help get all the codes and add them myself the best I could, *if* I knew where would be appropriate :)

Fresh Berry Smoothie 13:15, 17 March 2013 (UTC)

Also I very much like the way the medium is done ^_^

Fresh Berry Smoothie 13:17, 17 March 2013 (UTC)

Related objects on race/organization articles

I'm curious what others' thoughts would be for adding objects related to a group/species to said group/species' articles - e.g., what Steam creature does in the See also section, but renaming that to "Objects" or "Related objects". This can be automated via adding said objects into the group/species' categories and then adding a DPL (or other form of automated listings) like the Type section but calling for object infobox instead. This could probably be extended to items (trophies specifically), though I'm less privy on that. Konig 12:46, 11 March 2013 (UTC)

A simple list of objects related to a race lacks context. Most objects are described/part of hearts and meta events, with individual objects labelled as landmarks. Mentions of objects related to the race can be integrated into the prose of the article.--Relyk ~ talk > 16:00, 12 March 2013 (UTC)

How would you fit Corrupted Ice, Corrupted Ice Core, Corrupted Ice Formation, Corrupted Ice Shard, and Dragon Crystal into Icebrood? Without being utterly eye-soring, I don't think its possible. It has as much context as the NPC lists. No object is labelled as a landmark - there are some in which a point of interest and an object share the same name and location - e.g., Grenth's Door - but such cases should (if not are) be split. Konig 21:21, 12 March 2013 (UTC)

Special event missions

We need an infobox similar to personal storyline infobox for these missions. We have the Living Story achievement names for article names. The missions have some fun aspects, it's like a personal storyline instance scaling up to level 80 using event chains without a reward, has cutscenes, and a chain of missions stuck under an achievement category umbrella. The icon is a golden version of the personal storyline icon.--Relyk ~ talk > 17:29, 28 March 2013 (UTC)

I was wondering if any discussions had happened on this. Currently the Braham: Help from the Legions one is rather awkward. Are we expecting to lay it out similar to the Personal Story steps? (Same headers, basically?). I think it'll work as long as we get the infobox and icons right. Someone found the various icons here: http://imgur.com/a/NDmMJ#48 (7 icons with the gold star) Vahkris 18:12, 28 March 2013 (UTC)

Personal story missions have only 1 overarching "event" with multiple objectives. The Living Story missions are more like dungeons, where they have a sequence of events with individual objectives. But yes, as I suggested to Claret, it would probably be best to write a single cohesive walkthrough for these missions instead of splitting stuff out over individual event pages. —Dr Ishmael

19:35, 28 March 2013 (UTC)

I agree, but I think it's OK to keep them split up while we're waiting for the end of the tale to come to the fore. Daddicus 23:05, 28 March 2013 (UTC)

I'm talking about the events within each mission - Rox in the Hatchery and Braham in Cragstead. There's no need to wait for anything else, we know everything in these already. —Dr Ishmael

02:46, 29 March 2013 (UTC)

^For now, I would suggest formatting like the dungeon pages, as the events are equivalent to dungeon event chains and ignore any infobox. We can have a Living Story nav at the bottom to link between the missions.--Relyk ~ talk > 03:52, 29 March 2013 (UTC)

I don't know the code enough to set up a new infobox (Living Story Infobox?). I've been using the Personal Story infobox for now, although there's a storyline setting I'd love to use to denote these as Flame and Frost, since it looks like we're going to have other Living Story arcs. Other than the epilogue, it looks like we're at the end of this arc. Vahkris 20:08, 6 May 2013 (UTC)

Dead ArenaNet blog references

Since ArenaNet updated their website to be all fancy and corporaty, the blog is gone, and we now have a couple hundred pages that reference the now dead blog links. A lot of stuff is now probably either outdated or common knowledge. Do we do anything about them? Maybe a pruning of dead links in general? --zeeZ (talk) 08:55, 7 April 2013 (UTC)

Maybe we should reach out to ANet and ask if they can restore it as an archive—or send us an archived version so we can put all the old posts on the wiki (anyone else remembers us copying literally everything to the wiki on GWW? What happened to that? :D) poke | talk 14:48, 7 April 2013 (UTC)

A lot of those posts are already on the wiki, and anything else can be grabbed using internet archive sites like the Wayback Machine. We can pretty much put everything on here if necessary (might just do that at some point this week, just add everything lore-related at least), so I guess the question is only what to do with the links. Vahkris 02:03, 11 April 2013 (UTC)

Feel free to make some “ArenaNet blog” article where you put that stuff on, similar to gw1:GuildWars.com news. In the mean time, I’ll try to get some archive. poke | talk 09:08, 11 April 2013 (UTC)

I've asked our team about this and will follow up with them. Using the Wayback Machine looks like a better idea, as the wiki community could simply copy to the wiki the content that it feels is relevant to the wiki (some of our blog articles seem less relevant from a game perspective). --Stephane Lo Presti talk 20:52, 11 April 2013 (UTC)

Map Completion Pages Formatted Weird When Zoomed in on Chrome?

Is it just me or is the alignment for all the map completion indented over and over for each new line when you zoom in 150%+ on Chrome for these pages. For instance on here. Fresh Berry Smoothie 18:39, 10 April 2013 (UTC)

I can reproduce that behavior; very interesting.

19:01, 10 April 2013 (UTC)

It's because the icons are floated and they're increasing in size faster than the line-height is, so they're stacking on one another. I don't really know how to fix it, but I don't think anyone would normally be zooming in that far to a wiki page. —Dr Ishmael

19:33, 10 April 2013 (UTC)

Deleting the line "margin-bottom: 0;" on index.php line 150 fixed it for me at multiple zooms. Not sure why it works, but it does!

Fresh Berry Smoothie 21:32, 10 April 2013 (UTC)

"line 150" doesn't help me any, what CSS rule is it in? —Dr Ishmael

01:44, 11 April 2013 (UTC)

I'm really sorry I missed this comment some how -- It's for the dd but listed under:

dd, dt, li {
margin-top: 0;
margin-bottom: 0;
line-height: 1.5384615385em;
}

Fresh Berry Smoothie 13:38, 22 April 2013 (UTC)

Does the problem still occur now? I haven't changed the CSS any (that specific rule is in MediaWiki:Monobook.css, fyi), but I did change the {{map icon}} template to use a static div rather than a floating span. The icons no longer "stack up" for me when I zoom in with Chrome. —Dr Ishmael

14:04, 22 April 2013 (UTC)

You are correct. I noticed that this morning, but thought it may have been due to Mac OS X. It looks good! Thanks for fixing it for my terrible eyes ;)

Fresh Berry Smoothie 21:44, 22 April 2013 (UTC)

Automatic item stat lookup

I've made some fairly drastic updates to how {{weapon infobox}} works, and I figure I'd better stop and give people a chance to provide feedback before I take it any further. I plan to mirror these changes in both {{armor infobox}} and {{trinket infobox}} if everyone's happy with them.

The basic gist of these changes is that they make it simpler for editors to create pages for equipment. Since all item stats (with a few very specific exceptions) are determined by the type, level, and rarity of the item, I thought, "Why do we make editors enter the stat numbers on every single item on the wiki?" This was a no-brainer: they shouldn't have to. So I started tabulating the stats from all items in the game, with the hope of deriving formulas. Unfortunately, I wasn't able to find simple formulas that fit every data point - we know that item type and rarity each apply a single scaling factor to the values, but the problem is with level scaling. I can get a good fit (R² = 1) with a quadratic trendline, but when I try calculating values from the trendline, I get discrepancies of 1 in both directions with no discernible pattern. Adjusting the coefficients would make some values better, but only by making other values worse. I tried standard rounding and both ceil() and floor() functions, and nothing worked exactly. If anyone with better statistical skills wants to try, feel free to download my spreadsheet.

In the absence of formulas, I figured lookup tables would work just as well, other than the fact that they don't contain values for every possible combination - they only contain values for every combination that currently exists. They may require a bit of maintenance to add values for new combinations that get introduced in the future, but this should be a very infrequent occurrence. They also don't cover ascended items yet, but I'm working on it.

Anyway, getting to the point, I created [{{item stat lookup}} as the entry point for these lookup tables, which exist as subtemplates of it. Required input is the item's type, level, and rarity, and armor class for armor items. The looked-up values are stored in #var: variables to be used as needed.

The updated weapon infobox performs this lookup near the top of the template, then uses the variables {{#var:min strength}} and {{#var:max strength}} generated by the lookup to display the weapon's strength range.

I also created {{prefix attributes}} as a simple way of describing the attribute bonuses granted by an item. All known prefixes are well-documented at Item nomenclature, which made this another no-brainer: just have the editor reference the nomenclature to find a single word that completely describes all the bonuses. Of course, there are some weapons that don't fit a standard prefix, so I left the existing | variables = functionality in place.

End result: instead of entering up to 7 numbers to describe all the stats for a weapon (min/max strength, defense if it's a shield, 3 attributes), now you only have to enter 1 - the weapon's level. Along with the type, rarity, and prefix, this enables the infobox to lookup and display all of the weapon's stats automatically.

For clear examples of this functionality in action, see Wurm Lodge Warhorn and Mystic Hornbow.

I'll now open the floor to feedback. If no serious issues are raised, I'll go ahead and implement these changes in the armor and trinket infoboxes after a few days. —Dr Ishmael 20:23, 11 April 2013 (UTC)

Oh hell yes! Scary enough, I was actually thinking just a couple days ago while adding a bunch of items that since these stats are obviously generated either through an algorithm or table that we should be able to just put the type, level, rarity, and prefix to get the total stats, but I didn't know how to do it (was thinking of suggesting it here). I love this idea. Unless we can figure out the algorithm (if there is one at all), lookup tables might be the best plan. One extra thought I had, and this might need to go somewhere else for a full discussion, was adding a "skin" variable to the weapon/armor infoboxes so we could make it easy to attach which skin goes with the weapon/armor for those looking for a full set of a specific skin. I'll bring that up elsewhere, but this will save me a ton of time filling out the stats at least. Vahkris 23:45, 11 April 2013 (UTC)

I'm almost certain that there is a formula, the problem is that I have no idea where the baseline is. Like I said, rarity and item type apply their own factors on top of the level scaling, and there's no way to know which rarity or which type serves as the baseline that all the others apply that factor to. We can guess, but none of the guesses I've tried have worked out. —Dr Ishmael

00:58, 12 April 2013 (UTC)

This is great! Also I assume that as a result of this, and essentially the adding of tags to say what type an item is, soldiers/rabid etc, we could in theory have auto categories or something similar to for example, show all swords with rabid stats. This sort of thing is invaluable if you are trying to search for a stat type on the trading post, but don't know specific weapon names that might use it. --Lemming

13:00, 7 May 2013 (UTC)

Not categories, but yes, you can generate lists like that using Special:Ask or the {{#ask}} function. I haven't propertized the prefix yet, but that's a good idea! —Dr Ishmael

14:14, 7 May 2013 (UTC)

Places where Exotics can drop

The more different exotic pages im reading over time, the more more or less "useless" information i find about the places where they drop. Except for certain exceptions like Final Rest and most of the other event bound exotic items (Pillar of Ulgoth etc.), exotics can basically drop from any mob, chest, WvW loot bag etc. (whereever any loot can drop) so basically anywhere. So what i am asking here is persmission to delete "useless" drop information and replace it with a sentence like "This item can drop, like most exotics, randomly from any chest, any mob or any WvW loot bag as well as from the Mystic Forge.", or something like that. (Of course only on item pages where i know they drop randomly, like Zho's armor etc.) Magistrella 19:39, 12 April 2013 (UTC)

Please! I hate this too. —Dr Ishmael

19:44, 12 April 2013 (UTC)

Allright, will get to it when ever i see it. I will start with the precursor weapon pages and make them consistent. Then ill go over whatever crosses my way Magistrella 19:46, 12 April 2013 (UTC)

This is very true, very few items feature on a single drop table, with the exceptions of Final Rest as you mention, and the specific dungeon trinket receipe's, and the recent Molten facility chest drops. I can't think of much that else that is! --Lemming

13:02, 7 May 2013 (UTC)

World pages

Compared to the gw1 wiki there are still personal user pages but no longer guildpages (am I right??). What would be a welcome addition (in my humble opinion) are world pages. A page bout each world, wich is linked from the list on World. The page would have a tag above it that it isn't official information and is community based. No guild recruitment allowed, but a way to let worlds show themself. This can include information bout activity times (like e.g. be3ing an Oceanic world). Information bout a world teamspeak server, but also the specialisation. e.g. an (unofficial) RPG-world or a WvW-orientated world. Each world is encouraged to present themselfes in the way they seem fit, but offcourse with rules that where bout the same as the guild-pages on the gw1 wiki. Your opinions please?? 195.240.63.18 08:25, 18 April 2013 (UTC)

SMW data rebuild

Something is really borked with {{Property:Gives attribute bonus}} - it looks like all data is stored correctly on the property page and when using Special:Browse, but querying it with #ask only returns sporadic data. In an attempt to fix this, I'm going to initiate a complete rebuild of our datastore. I don't know how long this will take, since it has to trickle through the job queue, but anything that relies on semantic queries (e.g. trait lists) will go blank, then slowly repopulate as the pages are re-parsed.

I'll put up a site notice so everyone is aware of this.

P.S. Please don't make any edits to semantic templates during this time, it could confuse the rebuild process.

P.P.S. Admins can track the progress at Special:SMWAdmin. —Dr Ishmael 12:39, 18 April 2013 (UTC)

Implementing that as a job queue service was really a good idea… *sigh* xD poke | talk 17:11, 18 April 2013 (UTC)

There's a PHP script that can be run from the command line, but since we don't have shell access... —Dr Ishmael

18:55, 18 April 2013 (UTC)

Well this explains my problem /sigh--Relyk ~ talk > 20:04, 18 April 2013 (UTC)

It’s over now (probably for a longer while already). poke | talk 00:40, 19 April 2013 (UTC)

Automatically adjusting UTC times

Inspired by a very recent discussion, I quickly made something that would automatically convert our UTC time zone listings into the user’s current timezone (taken from the browser). See this working example. Two questions: Is this something we would be interested in? And which style do you prefer, or do you have another idea? poke | talk 17:56, 20 April 2013 (UTC)

Definitely would like that. Is the time offset user preference the same as the current timezone taken from the browser?--Relyk ~ talk > 18:07, 20 April 2013 (UTC)

Unfortunately my solution would always take it from the browser, while in the preferences you can set it the way you like (or also take from the browser). It’s not possible to get the preferences from JavaScript though (unless you want me another wiki extension—which could remove the need for JavaScript completely though). poke | talk 18:19, 20 April 2013 (UTC)

The hover over is probably the best solution, that way we get to keep the consistant UTC times + has the least kludge following it to the observer. Would we need to wrap the times we'd type in anything, or would it just recognise "<digit><digit>:<digit><digit> UTC" and convert it without any wiki-code being added to the page? -Chieftain Alex

18:29, 20 April 2013 (UTC)

A hover over won't work for most anons and some users because they want to see it at a glance.--Relyk ~ talk > 18:52, 20 April 2013 (UTC)

For that reason, I prefer option 2 1. pling

18:56, 20 April 2013 (UTC)

Hover-over won't work on mobile devices.

18:57, 20 April 2013 (UTC)

Pling, did I understand you correctly there? “Hover won’t work for most anons” – “For that reason, I prefer hover”? ;D poke | talk 19:00, 20 April 2013 (UTC)

Pling has a deep-seated prejudice against anons, but it's not his fault. His mother taught him to never talk to strangers.

19:03, 20 April 2013 (UTC)

Yeah, meant option 1... pling

19:05, 20 April 2013 (UTC)

Speaking as an anon, option 1. Would it also make sense to mention PDT/PST since that is the server time for NA worlds? ANet also uses that time for many announcements. 75.37.19.169 19:17, 20 April 2013 (UTC)

Well, it would always use your timezone, so it would only show the most useful time for yourself. I don’t think another PST/PDT would be necessary there; but of course we could just add that as well. poke | talk 19:28, 20 April 2013 (UTC)

Just give it an id tag so it can be custom formatted eh :p -Chieftain Alex

19:46, 20 April 2013 (UTC)

Oh yeah, forgot to answer you ;P My original solution used the HTML5 time tag, which would have somewhat guaranteed a machine readable date/time format. But I quickly learned that MediaWiki strips those tags… <_< So I chose a span tag with a custom class name instead. Currently it requires a fixed format, i.e. HH:mm UTC, but when MW supports data attributes (starting with 1.17, yay… ^^) I will move the time format in there and allow any content. In any way, I would put all that within a template anyway.

So, before adding all the stuff, are there any more suggestions on the format? Maybe a different text to make option 1 a bit shorter? poke | talk 20:14, 20 April 2013 (UTC)

"xx:xx UTC (xx:xx UTC+x)" unless we have to tell people they have a time zone--Relyk ~ talk > 20:40, 20 April 2013 (UTC)

(Edit conflict) ^ seems legit. WvW matches end every week on Friday at 22:00 UTC (00:00 UTC+2). -Chieftain Alex

20:42, 20 April 2013 (UTC)

Eh, I'm late to the party (spent the past 6 hours detailing my car - it be SHINY :D ), but anyway... I prefer option 2 for being compact, however, I understand the need for mobile/etc. compatibility. So I'd be fine with a concise form of option 1 - although I have no suggestions for said concise form right now. —Dr Ishmael

20:43, 20 April 2013 (UTC)

I like that suggestion, Relyk. Maybe even combine those two by setting a mouse-over on the user timezone “Yes, this is your timezone!” ;D poke | talk 21:27, 20 April 2013 (UTC)

Baha, pretty much like Alex already did there (just saw this after I clicked save ^^) poke | talk 21:28, 20 April 2013 (UTC)

Okay, it’s there: Template:UTC time. See it in action here. As always you might need to CTRL+F5 for it to start working. I hope nobody minds the IE9 requirement… otherwise I’ll refactor that bit. poke | talk 01:06, 21 April 2013 (UTC)

Nice one, good work. -Chieftain Alex

01:09, 21 April 2013 (UTC)

Do you mean that for IE it requires version 9? It works for me in Chrome, so I assume you don't mean it requires IE9 only. —Dr Ishmael

02:08, 21 April 2013 (UTC)

Can we get a dotted underline for the mouseover part? pling

02:11, 21 April 2013 (UTC)

Ish: Of course it’s supported in non-IE browsers :P But for IE, you need IE9 or later for it to work. All other browsers work fine.

Pling: Done. poke | talk 02:18, 21 April 2013 (UTC)

Btw. good news: After the wiki update, we can get a user’s timezone from the preferences. So people can customize what they see. poke | talk 02:23, 21 April 2013 (UTC)

(Reset indent) I would suggest adding a way to make it 12 hour alot of people like seeing am pm ect- Zesbeer 03:11, 21 April 2013 (UTC)

Rytlock’s Critter Rampage

I would love to make a wiki article for it :P--Relyk ~ talk > 19:23, 20 April 2013 (UTC)

There is absolutely nothing stopping you from doing so. Also it is super hard.

19:34, 20 April 2013 (UTC)

I haven't got past the bunny yet. It's always nice to ask!--Relyk ~ talk > 23:00, 20 April 2013 (UTC)

I couldn't figure out how to even damage that damn bunny. >.< —Dr Ishmael

23:01, 20 April 2013 (UTC)

I cross-countered the bunny and kicked it in the face for its last health at the same time it killed me. Everything on the screen exploded and I went back to the save point anyway.

23:15, 20 April 2013 (UTC)

You can kick it? I thought you had to kill the bunnies it spawns...--Relyk ~ talk > 23:23, 20 April 2013 (UTC)

The game ended when I kicked seven hells out of the enormous bunny. where did they put the other 6 secrets? -Chieftain Alex

01:09, 21 April 2013 (UTC)

Actual Skill Activation/Duration/Cooldowns

Hey, I've been documenting the actual times on thief weapon skills, from when you activate it, to when the damage numbers appear, to how long it takes to use another skill. Some skills are instant cast alongside the usual skills that need to be queued up, so I've ignored those. Is there any place on the wiki for this information? I know we added skill coefficients, so I'm curious whether we want to add something like a skill coefficient/time dps kind of deal. Fresh Berry Smoothie 13:02, 24 April 2013 (UTC)

If you can commit to doing that research for all skills in the game (or at least all standard profession/racial skills) (or get other people to help you), then sure. The only reason I tend to oppose things like this is because it's difficult to get people to complete a project of this scale, and it ends up looking bad for the wiki if its only documented partway.

Since this is unofficial information based on player research, my personal feeling is that we shouldn't include it in the infobox with the "official" skill data. Make a template for it, call it "skill timing" or something, that displays a table in the Notes section. —Dr Ishmael

13:15, 24 April 2013 (UTC)

Ah okay -- That all makes sense to me. I'll come back once I've completed 3 professions worth of weapon skills.

Fresh Berry Smoothie 13:28, 24 April 2013 (UTC)

Feel free to post the data you have in your userspace, or link to a Google doc or something, while you work on that. —Dr Ishmael

15:00, 24 April 2013 (UTC)

Actually, feel free to put it in the mainspace, to encourage others to help you either collecting the data, or at least presenting the data in a nice way. poke | talk 15:58, 24 April 2013 (UTC)

^ so if you put the data in a template then you can tinker with the appearance as you go along -Chieftain Alex

16:15, 24 April 2013 (UTC)

I'm not sure how templates work though. Maybe I should put it in the "discussion" area? So others can edit it?

Fresh Berry Smoothie 17:15, 24 April 2013 (UTC)

I don't see harm in putting it in the project space. We can have activation delay and aftercast delay numbers, but there aren't other properties consistent for skills. I do not like the "dps" numbers people want to post. These numbers don't reflect in important information because people don't fight using autoattacks and can only do it with chain skills. People can calculate the dps from the delays, so it's feasible to do that on a page.--Relyk ~ talk > 18:30, 24 April 2013 (UTC)

Hey everyone, it's been a long time since I've updated here, but I forgot to tell you that I went through many Thief skills. & I went through the Warrior auto-attack skills.

I'm failing to see the pattern between in game channel/cooldowns and real-life time required. There are some cases where you can make it work with rounding, and then others that do not. So I thought maybe each weapon has it's own unique time in between? Or there are different "types" of inherent cooldowns? Or my frame-drops caused issues? (I tried to keep it steady at 50 fps).

If someone could help me make sense of this, I'd appreciate it. Otherwise, it might be a good idea to quit this project (which would be sad, but I had kinda thought it might come to this). You can view it in my userspace right now. Fresh Berry Smoothie 14:10, 28 May 2013 (UTC)

Locator maps, a potential furthering?

So, this could be a terrible idea, but here goes: We already have (or are in the process of making) the locator maps (eg File:Gotala Cascade locator.svg), which have the outline of the areas of a zone, and one area in red. However, when they're used in the zone infoboxes, they're just static images. What if, instead, we were to have an imagemap extension, and we had a template (for the example above, {{Brisban Wildlands locator}}) which we could call with the area in question ({{Brisban Wildlands locator|Gotala Cascade}}) which would return an image map for Brisban Wildlands, but using the appropriate area locator? This wouldn't be difficult at all to integrate into the existing infobox, and the only real difficulties would be 1) getting the extension (as we'd need it, seeing as we can't use inline CSS or the HTML tags) and 2) the tedium of outlining the imagemaps when/if we were to do this.

But I think for this, the more important question would be is it appropriate?

PROS:
- It would allow navigation from one area to adjacent areas using just the infobox.
- With the outlines fully present, it appears to the user that it might be this way; that they can just click on an area to go there.
- It needn't be something just (or even in) the infobox. It could be put at the bottom as part of the zone navbox, perhaps on the right-hand side of the navbox, and show the current area the user is browsing (which wouldn't be difficult to program).
  - This point, however, is susceptible to the CONS of the overall proposal.
CONS:
- It would be overstepping the bounds of what the area infobox is currently defined as.
- Imagemaps? Those things suck.
- Would require that all the zones be mapped appropriately. This is something that has been done, but it takes a non-trivial amount of time, and while new zones are being mapped, this wouldn't work.
  - Again, this can (and currently, is) addressed within the infobox template; but this is still a point all the same, that it isn't just a simple "oh yeah, let me just right click the map and download from the client").
- Requires us to have another extension on the wiki, and one especially that might not be useful/usable for any other purpose.

There are bound to be more than what I enumerated above, and I'm positive that I'm not the first to propose this, but I thought I'd at least ask. —Jya voc 19:36, 25 April 2013 (UTC)

Right after I posted, I found this. Did anything come from this; still in the process, or cancelled, or am I missing that it was already added? —Jya voc 19:38, 25 April 2013 (UTC)

I don't know enough about SMW to be able to say yes or no properly, but I will say that I do keep trying to click on the different sections of those maps to move to that area's page, so actually having the functionality there would be beneficial...at least for me. Vahkris 19:43, 25 April 2013 (UTC)

Well fiddlemuffins. I thought I'd found a method to do this that wouldn't require image maps (by embedding the links within the SVG file), but I've been thwarted by MediaWiki - it converts SVG files to PNG for all display purposes, unless you drill down to the original file. If you go to [1] you can still experience the magic that could have been.

Anyway, yes, I think this would be a good idea. The only problem is that Anet's tech team is currently trying to finish up testing for the MW 1.20 upgrade, and I don't know if they'd be able to fit another extension in there. However, this is a Wikimedia-approved extension, so it shouldn't require much testing. I'll see what Stephane thinks. —Dr Ishmael

21:35, 26 April 2013 (UTC)

Wow I'd not noticed that all your svg maps had embedded links! (man those must have taken ages) -Chieftain Alex

21:48, 27 April 2013 (UTC)

That's the only one, I did it specifically for this conversation. —Dr Ishmael

21:49, 27 April 2013 (UTC)

Looks at date >.> fooled. -Chieftain Alex

21:52, 27 April 2013 (UTC)

(Reset indent) Now that Semantic Maps are in, is it something we can use here to create interactive maps and add event locations, etc? Or are there additional issues preventing it? Just checking. Vahkris (talk) 19:05, 21 May 2013 (UTC)

Unfortunately, no, because they removed the ability to define custom basemaps. "This functionality is currently broken and hopefully will be added in back in the next release." [2]. So we've basically got a useless extension for now. —Dr Ishmael

19:23, 21 May 2013 (UTC)

Bah, I had delusions of having zone maps that displayed the currently active events on each map (starting locations) using the new API. Vahkris (talk) 20:56, 21 May 2013 (UTC)

I did find this, though: https://semantic-mediawiki.org/wiki/Talk:Semantic_Maps#Using_custom_images_as_map_379 Looks pretty unofficial, though, so not sure it'll help us. Vahkris (talk) 21:00, 21 May 2013 (UTC)

Yeah, I'm aware of that as well, but the tech guys at Anet are really wary of doing anything "custom" with the wiki. —Dr Ishmael

21:17, 21 May 2013 (UTC)

masthead

I've implemented masthead links, mirroring the main GW2.com and the forums. This was discussed previously on Stephane's talk page, but it died out and the code languished in my personal css/js ever since. Now that someone brought up the lack of a link to GW2.com from the Main Page, I decided to go ahead and implement it.

It looks good for me in both Monobook and Vector, but please leave feedback if you experience any problems. —Dr Ishmael 19:51, 27 April 2013 (UTC)

For me these links don't show correctly. The link to support overlaps, see screenshot:

20:15, 27 April 2013 (UTC)

Should be fixed. Firefox computes a significantly larger font size for those elements than Chrome does, for some reason. —Dr Ishmael

20:19, 27 April 2013 (UTC)

it looks kind of out of place if the time/user/my talk bar matched it it would fit alot better. the other thing is that the there are alot of round curves in the wiki and that makes it stick out as well.-

Zesbeer 21:21, 27 April 2013 (UTC)

File:Relyk masthead.jpg, the transparent box is semi-transparent for me.--Relyk ~ talk > 21:44, 27 April 2013 (UTC)

Try removing all the masthead stuff in your personal css from when you were testing it relyk. (its applied everything twice for you!) Also you can remove the stuff from your .js too :P -Chieftain Alex

21:46, 27 April 2013 (UTC)

lul--Relyk ~ talk > 21:53, 27 April 2013 (UTC)

@ish, firefox has this awful property called "font-size-adjust" and its set to 0.52 on this wiki in the global wrapper and 0.43 in headers... supposed to improve appearance >.< -Chieftain Alex

21:58, 27 April 2013 (UTC)

(Reset indent) Firefox on a variety of PCs: nice addition. Currently, the background behind the links is high contrast dark red, so the "box" stands out rather than blends in, i.e. it stands out like a sore thumb. However, this is consistent with how it appears on the official and forum sites (support doesn't use the same design), so it's probably fine. 75.36.182.128 07:22, 29 April 2013 (UTC)

I just tried for myself to have the background transparent by default and use that darker background for the hover state. I think I like that more. poke | talk 07:42, 29 April 2013 (UTC)

I flipped the CSS, let's see what people think of it this way. Personally I feel like they don't quite stand out enough now. —Dr Ishmael

12:45, 29 April 2013 (UTC)

Looks great. -Chieftain Alex

12:53, 29 April 2013 (UTC)

I think it looks great too. It’s not supposed to stand out (and draw attention to it, away from the content) but just be there for convenience. poke | talk 16:38, 29 April 2013 (UTC)

way way better thank you. it dosnt stick out like a sore thumb any more.-

Zesbeer 18:57, 29 April 2013 (UTC)

I much prefer it this way.

19:02, 29 April 2013 (UTC)

Same. This looks great. I like how the box is seamless until you hover, and then it highlights so you know which link you are about to press. Kudus to those who worked on this. 75.36.178.111 19:39, 29 April 2013 (UTC)

Chiming in with everyone else. It looks really great, and I like that it opens in a new window by default. Vahkris 20:00, 29 April 2013 (UTC)

LOL :-D GW. Works fine in Opera... --OBloodyHell 01:19, 30 April 2013 (UTC)

(Reset indent) Just want to say thank you for the modification, it looks great in my opinion. I asked one of our graphic designer to take a quick look at it and the only suggestion he had is to make the text become an html link when you mouse over it (a bit like on our website). --Stephane Lo Presti talk 23:28, 29 April 2013 (UTC)

Ah, I did miss something. The problem is that the main website and the forums implement that differently: on GW2.com, the change on hover is that the color goes to pure white (#FFF), but on the forums the hover change is that it gets underlined. I was combining ideas from both implementations, and I ended up overlooking that bit completely.

So, would we rather have the links turn white on hover, or get underlined? —Dr Ishmael

01:31, 30 April 2013 (UTC)

Underlined, like most links are. pling

07:17, 30 April 2013 (UTC)

Most links except those in the wiki header. The page action tabs and the personal links don't get underlines. —Dr Ishmael

12:29, 30 April 2013 (UTC)

Using text-decoration:underline looks a bit heavy, perhaps if the background image it pastes in had an underline drawn on it might look alright. -Chieftain Alex

12:55, 30 April 2013 (UTC)

All good points, we're aware of the 2 different behavior. Something I forgot to mention: the "link behavior" actually makes a lot of sense given that the wiki also has "tabs". It helps improve (in our opinion) the user experience. But ultimately the wiki community can choose the solution that it prefers, and of course the one that can actually be implemented. --Stephane Lo Presti talk 18:12, 30 April 2013 (UTC)

I'm going to go with white-highlighting for now, avoiding underlines for consistency with the rest of the page header area. It can always be changed, of course. —Dr Ishmael

20:51, 3 May 2013 (UTC)

Related Traits on Skill pages

→ moved from User talk:Dr ishmael

For starters, that's not consistent with Endure Pain and more importantly it makes the wiki much less useful for theory crafting because you then have to open up several pages to access information which is easily and efficiently displayed on the skill page. Currently skill pages are big blobs of white with a tool tip and obscure path ways to finding relevant information. It's unnecessary to keep this stuff off of the page and it's a hindrance to send people to several other pages to find the same information you can easily display on a single page (most of these pages are barren of information because it's split into several different pages). By presenting all relevant traits on the skill's page it the shows user at a glance what they can do to modify that skill. It's also misleading to have a title called "related traits" when you aren't listing all related traits, just skill specific ones. That might lead people to falsely conclude that the only way to modify some skills are only the ones listed (a lot of people won't even know what a "Skill Type", such as Survival, is let alone look for a trait which modifies them. In addition to all that, skills which uniquely interact with traits (such as Healing Spring and Vigorous Renewal) will be confusing without mentioning that the trait exists in the first place. Currently the page mentions Vigorous Renewal on each pulse when someone reading this page has no idea what Vigorous Renewal is.

By formatting your wiki in this matter and dividing information in unnecessarily divided pages and strict adherence to poorly thought out policies you are hindering the purpose of the wiki - to inform the user. Currently the wiki is doing a very poor job of informing users with the information they want or need and it's becoming more and more obsolete. Policies such as this one are a hindrance to improving the wiki and a deterrent from people even bothering to use it for information let alone edit it in hopes of contributing to something useful. Typical wiki bureaucracy. I now understand why this wiki has fallen woefully short of the usefulness and audience of GWW and why there is no reliable place to find skill and trait specific information (most players are consequently ignorant of the details of these things) and why websites such as Dulfy's have become far more prominent in informing the GW2 audience when this wiki should have every advantage. I don't have time to deal with wiki bureaucracy every time I try to improve the wiki (note I have no problem adhering to formatting guidelines and policies, I'm not interested in arguing to change wiki policy when its a hindrance - that's a waste of time). I was going to spend a few hours ensuring the information contained in this thread: https://forum-en.gw2archive.eu/forum/professions/ranger/Ranger-Skills-and-Traits-Clarifications-Fixes/first (an example of the kind of research the wiki community from GW1 was very comprehensive about documenting and something which is sorely lacking from GW2W) was properly documented on this wiki so that people looking to better understand their class could do so by reading this wiki, but these kind of policy hurdles kill my desire to contribute. Good luck with your bureaucracy. 58.110.35.4 18:14, 2 May 2013 (UTC)

It's called data normalization. It's the same reason we don't specifically state that a Krytan Rifle can only be used by warriors and engineers - that a characteristic of all rifles, so we only document it on Rifle instead of documenting it on every individual rifle page. —Dr Ishmael

18:22, 2 May 2013 (UTC)

It is certain that manually copying/repeating information on several pages is not ideal for maintaining this data when it changes. I look forward, though, to the day in the near future (hopefully), when all the relevant info about a skill will be pulled together automatically on a single page so as to provide the full extent of added value that this wiki can offer, and I know you and others here are working day and night creating the tools to do that. Seeing everything the game allows you to do with/to a skill on one page is the ideal situation from the user's point of view. --Alad 01:00, 3 May 2013 (UTC)

The proposed solution of repeating data on multiple pages can make it harder in helping people understand the game. Too much text is just as harmful as too little: people can only absorb so much information in one article. I agree with the current community's consensus that information that is well-covered on an existing article need not appear on all articles that relate to that mechanic. In the examples above, Krytan Rifle does not need to cover all Rifle behavior, Healing Spring does not have to describe Healing, and Signet of Restoration does not need to explain how Signets work. Redundancy is good for backup systems, but not always helpful for learning.

Of course, there will be specific situations in which the underlying mechanics are unclear and some information should be repeated and/or covered again, but that should be dealt with on a case by case basis.

Finally, I realize Ishmael was the one who made all these changes, but shouldn't this discussion take place on a talk page for the community portal or a style guide? I'm sure the OP isn't the only one who feels that this topic is worth reviewing. It is often difficult to balance the level and type of detail used in wiki articles, so it might be healthy to reestablish the existing consensus. 03:00, 3 May 2013 (UTC)

Wiki is not a place for theorycrafting, it's a source for game facts. Most mechanics of skills and traits are properly documented and linked to on each article, making navigation easy. Currently the page mentions Vigorous Renewal on each pulse when someone reading this page has no idea what Vigorous Renewal is. This is why stuff is linked. If the reader is too lazy and not interested to find more about how this particular trait functions with this skill in comparison to others, that is their own shortcoming. That is exactly the kind of problem GWW had, where every skill had a large number of notes about how they played with certain mechanics and effects. This is also true for GW2; behavior of Vigorous Renewal when using Healing Spring is completely irrelevant if you're not playing a ranger with at least 10 points in that trait line – overall it makes a very, very small difference and is definitely not worth describing the entirety of the trait and all of its functions and relations on the skill page. It is simply enough to mention what difference it makes, and keep rest of the information in one place for easy management and logical accessibility. Personally, I feel that players should learn to play the game and memorize the traits they use without relying solely on the wiki for game information. ...a lot of people won't even know what a "Skill Type", such as Survival, is... Yeah, that's what I'm talking about, and that's why we link everything. Mediggo 04:00, 3 May 2013 (UTC)

Of course explaining everything would be impossible and undesirable. Simply listing the skill's connections to traits, combos, and whatever else (other class skills or traits) has an effect on it, or which the skill affects, in such a way as to see all that can be done in terms of traits, at least, would be a nice bird's eye view which enhances understanding of a fairly complex system. You'd like to know which skills to equip, and which traits. A help from the wiki's "computing power", listing the interconnections, can suddenly make things a lot clearer. The only things that would then need manual intervention would be the few details that aren't documented, such as in the current Notes sections. Of course this assumes the generously volunteering people working here have the time and inclination to do this. --Alad 06:41, 3 May 2013 (UTC)

I have an urge for a "Traits related to skill/weapon type" section so people stop complaining about being ignorant of skill types or cannot click a link.--Relyk ~ talk > 15:51, 3 May 2013 (UTC)

Use {{see}} under the Related traits section to link directly to e.g. Signet#Related traits. —Dr Ishmael

15:53, 3 May 2013 (UTC)

This whole wiki wouldn't have a reason to exist if people knew everything, Relyk! :D The more it helps people understand, the more useful it will be. --Alad 18:17, 3 May 2013 (UTC)

Ironic post

This page is getting rather massive can someone who is caught up with all the discussions please archive the resolved ones?- Zesbeer 21:07, 3 May 2013 (UTC)

Archived the first batch now. Didn’t want to tear the other topics apart (i.e. archive some from in between of the page). Maybe if Relyk resolves that icon template thing soon (*hint hint*), we can continue :P poke | talk 22:54, 3 May 2013 (UTC)

Tonight’s update

I just wanted to give you a heads-up on tonight’s update. Since MW 1.16, there were quite a few visual changes we will get when the upgrade to 1.20 is completed. This will unfortunately cause a few problems with our custom styling. The biggest issue is our standard table style for sortable tables. When using sortable tables, MediaWiki will now generate a separate thead tag where all the header values are stored within. This will unfortunately break our header row styling, causing the headers to have no background and the first data row to be displayed as a header. As such our custom styling needs to be adjusted for that.

Apart from that, there are some minor issues with headers in Monobook. As far as I am aware, this will not affect article pages at all, but only some few special pages (Special:SpecialPages for example). This should be simple to fix.

On Vector, we will have a few more issues. For one the tabs will have some issues (for example the watch-star will display incorrectly). Also the navigation on the left will have some sizing issues. (Sorry, can’t really give you details right now; I’m writing this off the top of my head)

Overall it is probably simple to fix but I wasn’t really able to prepare fixes for it before the update (to be honest, the way the CSS is written just confuses me a lot :P). But it would be nice if anyone could be around later tonight after the update and try to fix some of the issues (especially the table-one), as I sadly won’t be around when the update completes. poke | talk 10:46, 8 May 2013 (UTC)

I think the table header fix will be fairly simple. All we need to do is remove the "> tbody >" level in the selectors for tr elements. E.g.:

.table > tbody > tr:first-child > *,.table > tbody > tr.heading {

Would become:

.table tr:first-child > *,.table tr.heading {

I'm not really sure why Alfa bothered to put the tbody level in there in the first place. —Dr Ishmael

12:53, 8 May 2013 (UTC)

Had to switch off of vector that skin is just way to broken right now =/---

Zesbeer 01:08, 9 May 2013 (UTC)

Do we have a known fix for the table header issue and is it something I need to apply to the tables on the pages I've been working on (guild mission pages in particular, except the main one)? It looks off right now. Vahkris (talk) 13:25, 9 May 2013 (UTC)

Yes, see my post above. No, it'll be CSS changes. —Dr Ishmael

13:59, 9 May 2013 (UTC)

Is there any reason you didn’t apply it yet? ^^ (I just woke up :P) poke | talk 14:11, 9 May 2013 (UTC)

Because I've spent the past hour testing it. It's not as simple as what I posted above, but it's still not very complicated: replace tbody > tr:first-child with :first-child > tr:first-child. I still need to do a final test after find/replacing all instances of that to make sure it doesn't break anything, then I'll implement. —Dr Ishmael

15:04, 9 May 2013 (UTC)

I would also like to mention that I hate the minification that MW performs now. Makes it extremely annoying to edit CSS on-the-fly for fixes like this. —Dr Ishmael

15:13, 9 May 2013 (UTC)

Fix is in. I only did limited spot-checking, but everything I did check looked perfect. —Dr Ishmael

15:38, 9 May 2013 (UTC)

Same. I found this page which explains how to turn the minification off (but it still seems to merge the separate CSS files together into one and use load.php, even though it claims it won't in debug mode). -- Dagger (talk) 15:47, 9 May 2013 (UTC)

Jeweler/Recipes Grouped/Platinum#Ring - looks broken, extra borders on the right, and on the left, of the crafting bit. -Chieftain Alex

15:53, 9 May 2013 (UTC)

…that’s what the tbody was for… bleh. poke | talk 15:57, 9 May 2013 (UTC)

Nested tables are kludgy in any case, but it should be fixed now. —Dr Ishmael

16:02, 9 May 2013 (UTC)

Job queue statistics

In MW 1.17, they removed the listing of the job queue from Special:Statistics. Personally, I find this stat quite useful when I've edited a template and want to see when all the pages have been re-parsed, so I wrote a few lines of Javascript to restore it. Question: would anyone else find this useful? If so, I can copy it to MW:Common.js. —Dr Ishmael 16:01, 11 May 2013 (UTC)

Missing the thousand separating commas ;) but sure sounds like a good idea. -Chieftain Alex

16:18, 11 May 2013 (UTC)

Commafied. —Dr Ishmael

16:27, 11 May 2013 (UTC)

I’m not sure. While this is useful to us, others have no real interested in that and an additional AJAX request—I don’t know. And when we are interested in the value, we usually explicitely look for it anyway. poke | talk 16:41, 11 May 2013 (UTC)

The AJAX only fires when you visit the Statistics page; not may people even know that page exists. And it only calls the simplest of API queries, so I don't think we need to worry about performance. That API query is now the only way to see the job queue stat, btw. Still, I was only planning on making it site-wide if a lot of people wanted it, otherwise the few who are interested can just copy it to personal JS. —Dr Ishmael

17:13, 11 May 2013 (UTC)

Special:statistics is kind of a page that only people specifically interested in that info would visit, so I'm all for adding more info for those kinds of users. --JonTheMon (talk) 13:28, 13 May 2013 (UTC)

Is this in the common.js? I can't see the job queue stuff on the page. --JonTheMon (talk) 13:48, 21 June 2013 (UTC)

No, I never put it over there. It's on my monobook.js. —Dr Ishmael

17:56, 21 June 2013 (UTC)

Runes

{{upgrade component infobox}}
{{rune table header}}
{{rune table row}}
{{rune table footer}}
{{rune table}}

Rewrote the upgrade component infobox to just have 6 parameters for defining all the variables for rune stats. This makes it clearer in syntax and doesn't give listing an arbitrary order, obsoleting {{rune stats}}. All the other upgrade components will still use the variables parameter. This now sets the Has rune tier 1-6 properties. With the rune pages separated, we can set all the variables. The rune table templates can be used to generate a table. We will need a second rune table header or parameter for use on the rune page. The row template can be reused on the rune article, where the second parameter lets you abbreviate it. This could all be moved to "rune list table" templates instead. The {{rune table}} will display the three versions of the rune on the rune type, allowing navigation between the runes and replacing the three infoboxes on these pages. An example can be found on Rune of the Baelfire and the subsequent runes.--Relyk ~ talk > 08:19, 11 May 2013 (UTC)

I condensed things for you to reduce the number of templates required. I don't see why the header/footer need to be separate templates (especially the footer), but maybe you have a reason?

Also, I don't like the property names. "Tier" should be used for the minor/major/superior (since that parallels crafting and trait tiers), it doesn't make sense to use it for the bonuses. —Dr Ishmael

14:49, 11 May 2013 (UTC)

Splitting it up was so you can generate an arbitrary rune table, like listing all the superior runes or lists that have certain major and superior runes like boon duration. If you aren't going to do that, all you need is the rune table and output format. I prefer to put the header and the footer in a template as a good practice even if you can copypaste them.

I was using rune stat in the writeup, which sounded bad as not all bonuses are effects. I also don't like "rune bonus" as it's shortened from "attribute bonus" and bonus is somewhat vague. "Rune effect" would be good as it follows with "skill effect".--Relyk ~ talk > 15:28, 11 May 2013 (UTC)

Standardizing template parameter names

I’ve noticed this happen more and more: We are extremely inconsistent about how to separate multiple words in template parameter names. For example, {{Skill infobox}} has tool belt, separated by a space, and also weapon-slot, separated by a hyphen. {{Event infobox}} uses hyphens (map1-text), underscores (npc_map) and event combinations of both (npc_map-text). Others, like {{Location infobox}}, don’t use a separator at all (sstext).

I really dislike this inconsistency, because it is really confusing and makes using the parameters without dumbly copy-pasting them impossible. Parameter names should be simple to guess so adding information to infoboxes is easy. As such we should try to make them consistent and also self-explanatory, if necessary by making them more verbose (sstext is terribly ambiguous, especially when all other similar image description texts are <type>-text).

So I’d like to propose using spaces for separation only. There is no reason to use special characters; we are not bound to limitations of programming language parsers where a space is not a valid character inside identifiers. Instead, all uses of parameters are clearly separated from other markup (either using | parameter = value or {{{parameter}}}). And then similar rules as for article names should apply for parameter names.

For example weapon slot, map1 text (or even map 1 text?), npc map, npc map text, and screenshot text. poke | talk 17:47, 13 May 2013 (UTC)

This has bothered me for a while too, but it didn't seem like a big enough problem for me to raise a stink about it. I agree that connector characters are unnecessary, unless the parameter name is normally a hyphenated compound word, of course (dunno if any of our templates use any parameter names like that). We could even take this one step further, say that spaces are unnecessary, and convert everything to camelCase. I'm kidding about that, obviously... or am I? —Dr Ishmael

18:13, 13 May 2013 (UTC)

I hope you are :P And for the record, it’s your fault that I brought this up :P poke | talk 18:16, 13 May 2013 (UTC)

That's my fault. Probably thought you can't have spaces in parameter names. Replace everything with spaces. Numbered paramaters will be replaced with #arraymaps.--Relyk ~ talk > 18:25, 13 May 2013 (UTC)

Alright; then all new parameters should have spaces, and I’ll somewhen tackle a slow conversion for all existing ones (I’ll probably delay this a bit so the infoboxes can get their SMW magic completed first). poke | talk 19:15, 13 May 2013 (UTC)

Same page image zoom?

There are many extensions on the web that allow visitors of a site to click an image and have it expand their current screen instead of taking them to the next page which simply shows a File:[Image] page. Is it possible to add such a feature to this wiki? I apologize if this has been asked/answered previous, it was something that came to my mind today Fresh Berry Smoothie 22:07, 15 May 2013 (UTC)

Yes, there's mw:Extension:LightboxThumbs and similar. I don't think it's ever been discussed here, though. Personally, I hate it, and I know other people who think the same, so there would need to be a way to disable it from preferences if we ever installed anything like that. —Dr Ishmael

22:25, 15 May 2013 (UTC)

We could do this with weapon galleries, particularly semantic ones since they have the "overlay" feature available without any further extensions. -Chieftain Alex

22:34, 15 May 2013 (UTC)

Another possibility could be to add an overlaid "button" to pictures, so that can be clicked which activates lightbox instead. The other idea is that in the lightbox mode, once it's opened, it could probably be configured to have a link at the bottom that says "open in new window/tab" that would take you to where it normally goes, or perhaps another link that opens the full res in another window. I personally would be greatly in favor of this hybrid mode or the preference mode.

Fresh Berry Smoothie 23:18, 15 May 2013 (UTC)

Check out e.g. Gallery of axes. I forgot that Semantic Result Formats' gallery format had this functionality built-in, but Alex didn't. It works opposite of what you said, where clicking the image opens the lightbox (actually, fancybox) and there's a button in the corner to go directly to the File: page. I support this usage of it, since I can get around it easily. —Dr Ishmael

00:07, 16 May 2013 (UTC)

That is awesome. Thank you

Fresh Berry Smoothie 00:39, 16 May 2013 (UTC)

Going through that template page and it's discussion/edit, I'm a bit confused how to add pictures that use that extension. For instance say I want to add a map of a dungeon that can be zoomed in, how would I go about implementing that?

Fresh Berry Smoothie 00:42, 16 May 2013 (UTC)

I'll just go out on a limb and say my personal feelings are totally against this. It would feel very... wikia-ish. —Jya voc 00:52, 16 May 2013 (UTC)

That's exactly why I hate it. ;) But the SRF gallery's implementation is easy to bypass, so I'm okay with that. —Dr Ishmael

01:09, 16 May 2013 (UTC)

The reason I'd like it is because sometimes you're looking at a map and you just want to get a zoomed in version. Right now, I click on the image, then have to click on it again on the second page to get the big version. For instance, the new Karka achievements: You have a scanner and have to go around the map to find the locations. There is a map currently on the page that requires two clicks to get "full-sized". In that situation, I think people may benefit from being able to cross reference the table and the map without having to load new tabs/pages.

Fresh Berry Smoothie 02:52, 16 May 2013 (UTC)

You still can't get full-sized maps with a fancybox because the popup scales to fit within your screen (unless you've got super-high resolution), so it doesn't seem like that would solve your problem. Also, the popup would cover the rest of the page, so you'd still have to click back and forth to reference the list to the map.

Here's something that might help though: go to Special:Preferences, to the Appearance tab. In the Files section there's a setting for Image size limit - change this to the max value of 1280x1024 and you'll at least get larger versions on the File: pages (still not full-size for File:Plant Sample Locations.jpg, but it's enough to be usable for me). —Dr Ishmael

03:40, 16 May 2013 (UTC)

Yeah, you'd have swap back and forth, but it is still easier than loading a new page, and even if it's not full size it's still larger than the thumbnail. I've thought something similar might be interesting for things like guild mission maps (like bounties, treks, etc), so they could get the larger version without having to leave the page. Vahkris (talk) 13:07, 16 May 2013 (UTC)

See, that's what I don't understand. How is tab-switching any harder than opening/closing a popup? Tabs can be switched with Ctrl+PgUp/PgDn (or Ctrl+Tab/Ctrl+Shift+Tab, of course, but that contorts my hand too much), where you have to move your mouse, click on the thumbnail to open the popup, then move the mouse again and click on "Close" (or outside the popup) to close it. I find the mouse movements much more tedious than tab switching. —Dr Ishmael

14:31, 16 May 2013 (UTC)

My wife refuses to use tabs, and two other family members of mine who play MMOs would rather click using the mouse instead of using keyboard shortcuts for browsing, so it's something that's been on my mind. It's just a nice-to-have for me, though. :D Vahkris (talk) 15:01, 16 May 2013 (UTC)

(Resetting indent) Maybe something like this:

Array.prototype.forEach.call(document.getElementsByClassName("thumbimage"), function(i) {
  i.parentNode.href = i.src.replace(/thumb\//, "").replace(/\/[^/]+$/, "");
});

on your Special:MyPage/common.js might help. (Note: totally untested except for some fiddling in Firefox's Scratchpad.) -- Dagger (talk) 04:31, 16 May 2013 (UTC)

It should be either Array.prototype.forEach.call(...) or [].forEach.call(...).

That being said, we could start offering MW gadgets and have a lightbox as a gadget. poke | talk 08:39, 16 May 2013 (UTC)

We could if we had mw:Extension:Gadgets installed. :P —Dr Ishmael

14:27, 16 May 2013 (UTC)

Changed (although it does work for me). I originally wrote it as this:

for (let i of document.getElementsByClassName("thumbimage")) {
  i.parentNode.href = i.src.replace(/thumb\//, "").replace(/\/[^/]+$/, "");
}

which is nicer but currently Firefox-only. -- Dagger (talk) 14:40, 16 May 2013 (UTC)

Eh, Ish? I am sure we had it enabled shortly after the update o.O

Dagger: I don’t know why Firefox has Array.forEach but it really shouldn’t be there. poke | talk 16:31, 16 May 2013 (UTC)

I hate the lightbox thing. When I click on an image it's usually so I can get to the file page, so I can get the page title or the actual image url to send to someone. No more extra clicks please.

17:24, 16 May 2013 (UTC)

It's lovely for the galleries, I wouldn't like it anywhere else for that reason.--Relyk ~ talk > 20:05, 16 May 2013 (UTC)

@poke: we have mw:Extension:Widgets, not Gadgets. —Dr Ishmael

00:37, 17 May 2013 (UTC)

I'm surprised that so many people have such high expectations of the users of the wiki. I can tell you that many of my friends appreciate these small things for the reasons already listed above (tab switching is useful to those that can type, judging from what I see in LA map chat, that's not a lot of people *wink wink nudge nudge* lol). I can also obviously admit that for those that are editing the wiki or want the technical aspect of it that it would be annoying to implement this feature. However, on the option of a hybrid that appeases both parties, is that not possible? The gallery method is one way, and I personally think it's fairly easy to circumvent for both parties. It's also not very difficult to add a link to "full-res" or "image link" section to the 'lightbox'. And honestly, you'd be really surprised how much bigger my zoomed in picture on one page is compared to the actual second link. It's not as big as the actual full-res of course, but it's usually enough of a zoom and definitely bigger than the first click image.

Fresh Berry Smoothie 17:50, 17 May 2013 (UTC)

To follow up, not to mention that the current implementation hinders us from creating pages with too many images on the same page. Who would want to open 10 tabs of different guild missions, or if we had gone the route of showing in game pictures alongside the singular picture of the map on the karka sample things. We don't do this currently cuz it would just suck, plain and simple. And it would be hard to navigate the tabs. Some of us just have tiny brains and would much rather not swap between tabs looking for the right map or the right 'in-game picture'. I think such a feature will allow us to write better guides that are more geared towards, and informative for users. (I honestly don't believe the average user wants to go around opening a bunch of tabs, I think they'd rather use this lightbox feature).

Fresh Berry Smoothie 17:53, 17 May 2013 (UTC)

GW2 APIs

https://forum-en.gw2archive.eu/forum/community/api/API-Documentation Is there any way the wiki could utilize any of these or are they not compatible with MediaWiki? It looks like we can gather a ton of info out of these APIs. For example, there's one that lists every event name (looks like there's 1636 events total). Vahkris (talk) 21:07, 20 May 2013 (UTC)

oh wow, 24663 items in the game... we haven't even got that many pages on the wiki. Would require someone clever to extract all the info from the API into a format that we could use on the wiki. -Chieftain Alex

21:41, 20 May 2013 (UTC)

HOLY FUCK YES this is what I've been waiting for! Hopefully a skills API is next. —Dr Ishmael

22:09, 20 May 2013 (UTC)

BAM. First integration is live. Go to any event page and look at the bottom of the infobox. Have fun! poke | talk 23:09, 20 May 2013 (UTC)

Wow, we're only behind by like 200 event articles.--Relyk ~ talk < 23:18, 20 May 2013 (UTC)

Found a bug: clicking "Fetch" multiple times would expand the list continuously. Fixed by assigning an ID to the list and running .remove() on it before appending the newly-generated list. —Dr Ishmael

23:31, 20 May 2013 (UTC)

I originally wanted to remove the fetch button but forgot.. But re-fetching is more useful, yeah. poke | talk 23:33, 20 May 2013 (UTC)

I'm guessing this simplifies having a bot fill in item ids slightly.--Relyk ~ talk < 00:05, 21 May 2013 (UTC)

Could we make our own version of a dragon timer using this? -- pling

00:07, 21 May 2013 (UTC)

(edit conflict) “slightly” yeah, lol xD I’ll prepare the data tomorrow to let a bot run in the evening or on Thursday to get all the information in we currently get from the (static) API. poke | talk 00:10, 21 May 2013 (UTC)

The problem about those timers is that we need to store the history of the events to be able to calculate the next likely occurrence. And we can’t really do that. Unless ANet provides (or somebody else?) such information, we can’t do that well. poke | talk 00:10, 21 May 2013 (UTC)

Timers is one feature we can do without. I would like to add a collapsed fetch table for the Bonus Chest events (and split onto it's own page now), something readers would undoubtedly appreciate.--Relyk ~ talk < 00:21, 21 May 2013 (UTC)

Looking at my list of problematic events, "warmup" would include stalled events ie Bandits have constructed a roadblock to stop Shaemoor traffic showing on warmup on my server but really it is not. I am aware of its frequency soon after a server restart and it's so long overdue that it must be stalled. Also, Stop the bandit thief from stealing the pumphouse blueprints is on warmup but it only ever starts once after a restart and is broken even then. OTOH, Defend Farmhand Nevin as he transports his cocooned friend to safety which I have not seen for months is "Currently not active on any server". Does that mean it is no longer in use? Or what? Similarly, Drive the bandits away from the windmill. Protect Scholar Detti as she experiments on the power source an old holiday event shows no option to fetch. Interesting… --Claret (talk) 00:58, 21 May 2013 (UTC)

Presumably if its historical content it isn't listed in the API. (we could use that list of events to check if we've marked any as historical which are not) -Chieftain Alex

01:07, 21 May 2013 (UTC)

It’s not completely clear to me what the individual states mean exactly. I’ll try to research on that tomorrow in game. Warmup is meant to mean that the event is currently inactive and some other things are necessary for it to start (possibly previous meta events and such). The message “Currently not active on any server” means that the event is either “Success” or “Failed” on all worlds. I filtered those out as you don’t really get anything from a completed event, and simply to reduce the amount of output. I didn’t know that the warmup state was used that much as well. poke | talk 01:10, 21 May 2013 (UTC)

The warmup should be any timers and prerequisite events. Preparation should be any NPC movemet and dialogues that occur before the event actually starts, which might include start NPCs.--Relyk ~ talk < 01:13, 21 May 2013 (UTC)

So I guess the stalled events are locked in "Warmup". --Claret (talk) 01:15, 21 May 2013 (UTC)

Note, there are 80 copies of Stop the skritt burglar before it escapes with the treasure in the event list so we are a little less behind that was thought.--Claret (talk) 03:16, 21 May 2013 (UTC)

The known wiki events have "Rescue Mepi's moa herd from the bandits" but the lists have Rescue Mepi's moa herd from the bandit caves and do not have "Rescue Mepi's moa herd from the bandits". Hmm… Also some events like Destroy the blighted growth are in fact two events as they occur simultaneously. There are more than a few that I have never seen either in game or on the wiki and that's just looking at a couple of zones. Damn ANet, info but incomplete, another puzzle… :) --Claret (talk) 06:17, 21 May 2013 (UTC)

wtb some javascript(?) to generate event status for given world_id. I would totally do this myself if I knew how to code it.--Relyk ~ talk < 08:28, 21 May 2013 (UTC)

Later tonight. poke | talk 09:08, 21 May 2013 (UTC)

woo--Relyk ~ talk < 10:19, 21 May 2013 (UTC)

k guys so we need something like this http://mos.millenium.org/na/matchups/map/696 gogogogo people who are more skilled then i-

Zesbeer 20:02, 21 May 2013 (UTC)

I am working on a WvW tracker for Android.

20:20, 21 May 2013 (UTC)

I would LOVE to see temple open status by world, especially Balthazar. 174.16.209.47 20:15, 27 May 2013 (UTC)

you can use gw2state.com for temple status

Fresh Berry Smoothie 14:01, 28 May 2013 (UTC)

Just cause I can doesn't mean I want to. I'd rather use the wiki, the one all-knowing repository of all things GW2. 174.16.209.47 04:13, 30 May 2013 (UTC)

Event ID Redirects

With the new APIs released, every event is associated with a unique alphanumeric id. It would be fantastically useful to have a redirect for every one of those event ids to the corresponding event page. Does this sound feasible and useful, and is it something that can be automated?

For example [[4E5FDCA0-58C5-467F-A683-FF2490CEB43B]] would redirect to Defend Fort Cadence's southern entrance Kuang Eleven (talk) 18:49, 21 May 2013 (UTC)

That wouldn't be useful.--Relyk ~ talk < 20:20, 21 May 2013 (UTC)

Oh no, it would certainly be useful- you could take people to the wiki page for an event from its ID. But you could get the event's name from the ID and go to the event page from that instead.

20:22, 21 May 2013 (UTC)

(edit conflict) No that would only mess up our search (in GW1 we had a different namespace for game ids). Instead I would do this as SMW properties and actually already planned and prepared that. poke | talk 20:24, 21 May 2013 (UTC)

(double edit conflict) I can't think of why any tool developer would ever give only the event ID instead of simply using the API itself to decode it to the name. —Dr Ishmael

20:25, 21 May 2013 (UTC)

Oh, you certainly can decode an event ID to the event name, but that isn't guaranteed to go directly to the event page. For the example shown, the event_names displays the event with a final period, while the wiki name does not. The resulting search page does list the correct page, but adding the event IDs would give a direct link without dealing with string manipulation. Additionally event IDs are guaranteed to not change. I'm not familiar with SMW properties, would these allow for a direct link to an event page given the event ID? Do you have any examples set up? Kuang Eleven (talk) 21:42, 21 May 2013 (UTC)

I have not had the problem of reaching an incorrect wiki page yet from the event api's I've been using -- You may have found some, but I'd think they're in the minority. Could just fix them with a redirect on the wiki

Fresh Berry Smoothie 14:04, 28 May 2013 (UTC)

I have had a look in some detail at the events' list returned. Several events on the wiki can have multiple ids pointing to them, Stop the skritt burglar before it escapes with the treasure has 5 ids in Queensdale alone. Clear the Flame Legion cave near the Wrecking Yard has two ids, "Rescue Mepi's moa herd from the bandits" on the wiki is "Rescue Mepi's moa herd from the bandit caves" on the event list. There are wiki events with no ids, there are events unknown to the wiki. There are events that the activity option on the infobox never returns any information, what's the significance of that. There are events that are in "Preparation" constantly on every server, are they bugged? If it's possible to parse the id, that might be useful but I see no pattern on first glance. So, the ids are potentially useful but I am sure they have many interesting problems and wonder if some further study would be useful before much more is done with them in the wiki. Claret (talk) 07:31, 30 May 2013 (UTC)

What to do about this? (wiki culture/complexity)

→ moved from User talk:Pling

http://www.reddit.com/r/Guildwars2/comments/1f37tq/the_bifrost_is_really_detailed/ca6qkvw?context=4

The highlighted comment near the bottom. -- pling 11:41, 28 May 2013 (UTC)

Honestly, it seems like an adverse reaction to (perhaps improper) criticism/correction. There was a previous incident with that particular user with dye previews. At the time, he was just adding in placeholder text for future additions of information and didn't like that we said "Please only add it when you have actual info" [3] So, it's more that we don't have a good way of saying "Hey, that's not cool" or "We're in the middle of getting a good way of doing this" without making someone mad. --JonTheMon (talk) 13:24, 28 May 2013 (UTC)

Maybe don't say it if you don't have a method in place. "We'll have one real soon now" is vapour. It might well be that some people (the de facto core) don't like placeholders but sometimes they serve a useful purpose. As an example, the event infobox really wants a "real" area and if there is not one, does not provide the zone. So a stub/placeholder/minimal is useful. That's one example of what I might find useful, others may well have other uses for stubs/placeholders. Is it really so much of a problem to have some. I suppose 100s is a bit much but… Forgetting that, it's not just placeholders. Quite a few people that I know use the wiki as a resource but are put off contributing by what they see as responses.

As for the "discussions outside of a page's discussion page", well my impression is that's it's common. Not every contributor or potential contributor has the time and knowledge to ferret out the arcane bits and pieces. It's easy for those who grew up with the wiki, it's intuitive. But it's far from intuitive to newcomers. I have whinged about this elsewhere so will not go on but it's a real problem in my opinion. Obviously it isn't seen as such by others, but that's life. I am not really commenting on my own "problem" but there's some truth in the post you quoted and maybe you should be looking at that aspect rather than just looking for nicer ways to say "no". Also, if there's a good reason to say "no" then give it, but sometimes the impression is that a small core decide what is right and what isn't and impose their vision on the non-core.

Don't get me wrong, many things, once explained, make sense and I, and I would think most others, would have no problem following these explanations. Others seem arbitrary, with so poorly reasoned "explanations" that the logic seems to have gone on holiday.

Therefore, maybe look at the slightly deeper message in the post. It's not unnatural for a sense of ownership to develop but who really owns the wiki? If you put people off, than that's a problem. Just a thought or two. --Claret (talk) 14:02, 28 May 2013 (UTC)

So, is it a perception issue of what a wiki is that's a problem? Like, existing users see it as a "finished product" and newer users see it as a "sandbox to share ideas"? --JonTheMon (talk) 14:41, 28 May 2013 (UTC)

Whatever words I type here will not adequately cover all I feel and without a doubt will not cover what others feel. No, the existing core of users have a vision and a style in mind. They don't agree on every aspect but they are not too far apart. They know where the discussions are/have been held/in which archive they are. They own the wiki. You may protest that but it's true nevertheless. I'm not saying that this is altogether a bad thing and it certainly isn't unnatural.

Newcomers are at a great disadvantage, they don't know all the nooks and crannies where the information is, they don't know that something was decided in early 2012. They are put off by the seemingly arbitrary "rules", not the "reasonable" ones but the one's who's reasoning is, to say the least, obscure. There is a long way between policy/consensus that has a "reasonable reason" behind it and others that are, seemingly, personal foibles of the Old Guard.

I am far from saying that some of these policies/whatever are poor, they just seem to be to many people that I talk to. maybe I am talking to the wrong people but, looking at the recent changes page, I don't see many "new" contributors, spammers excepted. I may be wrong on that count, I have not formally counted.

Obviously, occasional hiccups aside, I can live with this. Other potential contributors are put off, however. They want to add some information but can see what happens, or are unwilling to accept some aspect of the corrections' process. Some correction is inevitable but sometimes it does seem excessive. It's like the news, no-one is too interested in the good news, but the bad news gets lots of attention. The corrections that get the attention are the problem.

There is a lack of perception, I think, as to how the potential contributor sees the way the wiki functions. It was interesting to see how it was questioned how to say "no" more kindly, not if it was necessary to say "no" as often.

In real life, I have to critically examine how I do my job on a fairly regular basis, sometimes the answers to that are not "comfortable". Not sure there couldn't be a bit of that philosophy here as to how the wiki functions.

A bit rambling but there's an answer. --Claret (talk) 15:35, 28 May 2013 (UTC)

A big part is just that most of the long-time editors forget what it's like to be new to a wiki. To be over-protective of your first edits, where you spend possibly hours researching or transcribing some aspect of the game to make it "good enough" to put on the wiki, only to have it reverted minutes/hours later by someone who then scolds us on our talk page about it. That leaves a really sour first impression, regardless of how "right" that person might have been to patch up the article and to comment on it to the contributor. Obviously there's no way to be politeness police - generally only the worst offenders/attitudes get punished by sysops, but it's the offhand comments made by experienced editors that are most off-putting to new users. They think they have a new way to tackle an issue and are promptly blown off by... well, everyone. And that's kind of the kicker. If poke (for example) says "that change is stupid, we should do this instead" I know I'm inclined to simply agree with him - he's been around for years, cares about the project, I trust him, etc. But that doesn't necessarily make his *ideas* any more or less beneficial than those of a newcomer. But because of the difference in weight/power/influence, the newcomers often get either completely ignored or shut down harshly (either actually harshly or simply taken as harsh by the newcomer), and that combined with the inherent complexity of wikis/archives/whatever is enough to make users wary of contributing.

Is there a fix? Who knows? It takes thick skin and passion to contribute to a wiki for a long time. A lack of either leads to quick burnout. Not everyone is cut out to do thousands of thankless, volunteer edits over the years; they often seek more praise than can be found on a wiki, and (I saw this with the PvP crowd in GW1, oddly enough) they just hate to be reverted or have their edits "mangled" by someone else, despite it being in the nature of any wiki. The wiki community can probably do its part to appear nicer, or at least be less quick to bite heads off for minor errors - but even that's not going to open the floodgates and pour thousands of new editors into our project.

For what it's worth, I wouldn't be opposed to some kind of attitude guideline page combining "you are valuable," "assume good faith" and "don't be a dick" into one short essay. New users can read it and hopefully gain some understanding of the old timers' actions and not be put off by them, and old timers can read it and hopefully bite less heads off for minor shit. -Auron 13:58, 4 June 2013 (UTC)

Much of what you say is unarguable. However, for me at least, the seemingly arbitary "we don't do it that way" is irritating. Especially when, on some research, "we" = "I", and they are the only one who things that way. Another matter would be for the "Old Guard" to actually back off all the new and fancy stuff and rewrite the basic templates, get the bugs out of their "functions" or whatever you call them. Fix the guidelines, argue the merits of what we have now. Don't go running ahead when the basics are still shakey. I know it's not as much fun but… Also, housekeeping like the deletions and silly redirects maybe should be done more routinely. There are many old ones there. I really don't wish to appear whiney or disparage the efforts of the regulars but <sigh> I think it should be said.

It's weird that some can be really kind and go out of their way to be helpful on one day and brusque and inconsiderate the next. Maybe the wiki is "schizo" inducing :) --Claret (talk) 14:11, 4 June 2013 (UTC)

Regarding out-of-place discussions, I think it'd be an even greater hassle to start moving all the old, archived discussions to where they "should be." Truly, it is way too bad if someone has missed a relevant discussion about formatting, consensus, etc. but they still shouldn't take it personally IMO. But yeah, some kind of "assume good faith" promotion would be really nice to see being put to use. Mediggo (talk) 15:33, 4 June 2013 (UTC)

I was not suggesting moving all the archives to their "correct" area. It would be easier to start the wiki over. No, just write up a "current pracice" and ask for comments. Then keep further conversations in the "right place". --Claret (talk) 15:38, 4 June 2013 (UTC)

Yes, of course, I simply spoke my piece about that seemingly exaggerated issue. I don't think any contributor should have any reason to doubt word of another user saying that "this particular topic was already discussed here" or take it as "you didn't take part in the conversation here three months ago so you can't improve on it". Mediggo (talk) 16:46, 4 June 2013 (UTC)

What's exaggerated? The fact that "dicussions" have been held and "consensus" reached by an all too often small number of, admittedly hard working and productive, contributors. This seems to be a cause of friction. Surely it's not asking too much to consolidate the information somewhat. If the wiki community can't admit that this goes on all too often then it's in a delusional state. It's far from just me who thinks so. I originally thought that I was a bit paranoid but seemingly many others (personal communications as they're shy, and posts on the wiki) feel that way and, possibly more importantly, it's the impression given on reddit.

Sadly, I have found that other people's word is not always as believable as one would hope. When you actually dig out some of the discussions, there was never actually any consensus reached, but the person interested in that aspect just went ahead. No problem with that in itself, but to say that's a consensus and then, almost in the same breath, criticise another de-facto consensus reached in much the same way and argue that there was some discussion, sometime, vaguely to do with the question, and so on… As we used to say, "What's sauce for the goose is sauce for the gander". All to often "you didn't take part in the conversation here three months ago so you can't improve on it" seems to be the attitude when "correcting" others but not when doing thir own thing. The behaviour is not constant but it's not uncommon too. If there's decent documentation in the correct place with room for discussing possible changes, also in the same place, then a great deal of the frustration and ill-feeling would disappear. Yet another 2¢ worth. --Claret (talk) 17:41, 4 June 2013 (UTC)

I meant that I find it hard to believe that any newcomer who has not interacted with wiki environment before would have any reason to not trust word of another, existing user. If that existing user has done wrong by, say, referring to a discussion which didn't actually reach anything concrete as a consensus, then that's entirely different problem in my eyes, even if it is a symptom of those discussions being archived in difficult to find places. However, regarding about what is consensus and what isn't, as far as I see it, if an article is edited, and nobody edits it further and no discussion is had, that revision essentially becomes a new consensus because nobody contested it further. That is my interpretation of this. So if somebody claims that a consensus about something has already been reached despite it not actually have been discussed by scores of users and nobody contested the revision/practice/whatever, I can't blame them, but of course that doesn't mean that consensus is something that is set in stone and cannot be changed or improved. That is what some commentors on those reddit threads seem to be thinking IMO. Mediggo (talk) 18:29, 4 June 2013 (UTC)

Thanks for your clarification. I agree with you. As to consensus being "set in stone", of course it isn't. Whatever you and I may feel or be persuaded to feel, it's a fact that people do feel that there are problems. I will not repeat them but I have suggested some solutions. Let's see if any of them are acted on. I will contribute my bit. --Claret (talk) 18:36, 4 June 2013 (UTC)

reddit

As suggested in a (now archived) section months ago, I've started a reddit q&a-ish thread about the wiki. -- pling 17:46, 31 May 2013 (UTC)

Good idea, count me in on replying to stuff there. poke | talk 18:23, 31 May 2013 (UTC)

Same here, although if you're not blind you probably noticed that. Vahkris (talk) 21:30, 31 May 2013 (UTC)

I'm going off now so I'll leave the replying to you guys. -- pling

21:40, 31 May 2013 (UTC)

(Reset indent) From reading the thread that is linked in the notice section few things are sticking out to me

people are unsure how to format things. (so improvement in this area seems to need to be done)
- So maybe there needs to be a project dedicated to formatting + getting pages started?
too many big egos and negative tones at other users.
And maybe we should consider some sort of way to give users thanks or kudos or +1's for contributions.(even though that isn't something that I necessarily agree with because I feel that editing the wiki is a thankless job)

On the topic that is raised in that post my feelings are thus: Other pages like dunfy and other api pages like dragon timers ect have more complete info and we should do everything we can to emulate and fill in where they have the same info. because whats the point of visiting the wiki if another site has the info you are looking for in a more user friendly way and has it up quicker.- Zesbeer 22:16, 31 May 2013 (UTC)

A wiki is not designed to be a dynamic data delivery platform, so doing anything like boss timers would require a great effort to shoehorn into the wiki framework. Outside of that, though, I agree with you. —Dr Ishmael

23:48, 31 May 2013 (UTC)

The user interaction thing is one the most important things we need to sort out, in my view. Figuring out how to edit pages and format them makes no difference if we don't accommodate the people trying to do so.

Treat people according to their intents. If someone makes a huge mess on a page and it requires fixing and deleting and cleaning up, so what, as long as that person meant to help out. If someone makes changes to a page without knowing about a discussion, don't be annoyed at them for ignoring discussion or doing things without consensus; say thanks, say other people might be interested in the project and here's where you could all discuss it - treating them as a member of the regular community straight from the beginning, not saying "here's what the regulars have said, go there if you want to be relevant".

And know your audience. You shouldn't be blunt to an innocent, fresh newbie who's only edited two or three or twenty pages, or to someone who's having trouble or getting flack. You don't need to talk to them like a robot, giving them the facts only and no encouragement or pleasantries. Even Auron uses smilies sometimes. This is something I have trouble with myself, so this is a very hypocritical comment, but I think there are better diplomats out there and maybe you'll have better luck.

"Be bold", "assume good faith", and "you are valuable" are probably the three most important concepts on any wiki, whether they're written policies or not. Perhaps we (or I) made mistakes in not enshrining those principles much earlier on. -- pling

10:36, 1 June 2013 (UTC)

It's interesting how the most outspoken contributors, who happen to be in positions of power, have in some way or another mentioned they are not the most tactful individuals in the world. I wonder if isn't that what the reddit users were talking about when mentioning the "mods". Erasculio 03:10, 3 June 2013 (UTC)

It's okay though, because I am the most tactful individual in the world.

05:21, 3 June 2013 (UTC)

I must say as an occasional wiki editor, it does sounds sometimes as the monkey cage situation; This is a real behaviour experiment. Imagine a cage with 5 monkeys. In the middle is a ladder with on top a banana. As soon as a monkey sets foot on the ladder, all monkey's are sprayed with water. Naturally the monkey's are going to keep an eye out for each other to prevent them from trying to take the banana. Now the experiment continues. One monkey is taken out and replaced by a new monkey. Naturally the new guy tries to go for the banana. the rest stops him and warns him not to do so. Eventually all monkey's are replaced and still no monkey tries to go up the ladder, even though none off them knows or understand why that would be a wrong thing. The wiki works with concensus, but once concensus has been reached that shouldn't be treated as law and order. Everytime a new person comes in, he should be allowed and encouraged to renew any discussions precious held. So if someone makes a wrong edit, don't tell them how wrong they are, but talk with them. appreciate the effort and challenge them to question what we all take for granted.195.240.63.18 11:22, 13 June 2013 (UTC)

Grocers' apostrophes <sigh> --Claret (talk) 12:49, 13 June 2013 (UTC)

I don't think that's a valid comparison. The monkey cage experiment is not consensus, it is behavioral training. The monkeys didn't decide that it was bad to go up the ladder, they were trained to believe it was bad by being sprayed with water. —Dr Ishmael

13:08, 13 June 2013 (UTC)

Thank you Claret for proving my point. Instead of giving a comment bout what I'm saying and concerned bout you slap me on my fingers. Point proven. I tried, time to move along and share my knowledge with lesser pricks then some here. 195.240.63.18 13:33, 13 June 2013 (UTC)

Good riddance.--Relyk ~ talk < 13:50, 13 June 2013 (UTC)

As one who has had many slaps about many things on the wiki, you wouldn't believe... Your point was a false comparison as Ishmael pointed out. The problem on the wiki is NOT pointing out problems per se. It's (1) rudeness or the perception of rudeness (2) obscure or obscured documentation (3) the "consensus" is often of one (4) the apparent arbitrariness of the "rules" (5) the feeling of ownership that some regulars have. As to (1). The Internet is no longer the sole province of young men who use insults as banter. The rudeness is not mitigated by body-language or context. Personally, I welcome constructive and reasoned criticism, the ability to accept such criticism a sign of being an adult.

Regarding my link to apostrophes, sorry if you take offence but it's a valid point. Poor English, in the real world, reduces the effect of your argument. (So says one who corrects the BBC's English on occasion). --Claret (talk) 13:49, 13 June 2013 (UTC)

So my poor english makes me unfit to contribute to the wiki?? or makes that you can treat me as you treated me?? Like I said your reaction and others, with lack of self critism shows the community is too closed and narrow minded. Exactly like the monekys in that cage. But don't let me stop you from you private party. I know the GW2 community is much richer and friendlier and wiser then the average wiki contributor. 195.240.63.18 13:54, 13 June 2013 (UTC)

That might be a hard case to argue, the only friendly people I've met in-game are from my guild and the wiki. If you have any examples of your grievances, I'll go on their talk page and bitch at them. If it's my page, I'll probably vandalize with a wall of pikachus.--Relyk ~ talk < 14:01, 13 June 2013 (UTC)

I personally take grammar corrections as useful trivia, but yeah, there have been edit wars fought over grammar and spelling and such. Perhaps since it seems that correcting those seems so personal? I dunno. Anyhow, ways of speaking/spelling/wording do give users a certain amount of credibility, warranted or not. I think the (slightly buried) advice was: you'll get your point across better if it's in a nicer package. A bit shallow, but unfortunately that's true. --JonTheMon (talk) 14:03, 13 June 2013 (UTC)

I think the question you'll need to consider about the wiki: is it any worse than the general internet, and can it be made better? I think it's fairly good, but there are just some people who are detail oriented. Notice that Claret pointed out one issue, without being derogatory at all (perhaps it's a pet peeve?). I think that if you stuck with the wiki, you'd find ways to make it AND the community better. Pointing out things is an important part of any community (self-monitoring isn't always the most effective). --JonTheMon (talk) 13:57, 13 June 2013 (UTC)

I didn't say that your "poor English" made you unfit, I pointed out an error and gave you a reference to back it up. You're over-interpreting what I said. If you think that's critisism then you are truly too sensitive for a wiki. I have had to learn to live (after people corrected me) with the US version of English and its weird (to me) word usage and weird punctuation, it makes my spelling-checker cry. But, it strikes me that you have made your mind up and therefore will not take and more part of the wiki. Sorry to hear that, we need critical contributors. --Claret (talk) 14:13, 13 June 2013 (UTC)

One of the problem is communication. English is the only form of communication we have in this wiki and even though I am not native, I try to type proper English because I want to be understood correctly. Having said that I realize, that I am also handycapped, because I have no natural feeling for the tone of my writing. Also as a German I tend to construct to long senteces, start random nouns with capitals and have a strange understanding of how commas should be used. German is only partial related to English.

Another thing is of course the tone. The problem with wikis is that basiclly everything is up for discussion. So the first thing you need to bring with you is the will to discuss everything. This is has to happen in civil form. But the problem here is that even a civil discussion can be pretty aggrovating, when you have the feeling that the other one is not bringen new arguments or you have the feeling that the other do not want to see your point. Also there is a good chance that there was a lengthy discussion in the past about one topic and someone trys to enforce the consensus reached in this discussion. That doesn't mean that this subject can't be discussed again, but usually everyone who was part of the discussion, usually is happy with the consensus reached or simply had given up, etc. What I want to say that it can be hard to change an old consens and that is the second thing, everybody should be aware of.

Or to in an attempt to praprase the whole issue: 'The wiki is for all of us, which means, it is for non of us individually.' - Yandere

14:15, 13 June 2013 (UTC)

Hey, I’m going to skip over the monkey-thing part, and just respond to what you actually criticized.

“concensus […] shouldn't be treated as law and order.” — You are right, and that’s also how we see it. Consensus is used to agree on stuff (note btw. that it is consensus, not voting; we try to get participating people to understand why one thing is better than the other, so they will ideally agree with it as well), and based on that we do what we do. If there are valid concerns about something, then of course anyone can raise these concerns and start another discussion about it, aiming at a change. Now because the previous consensus, of course there will be people defending what has been decided before, so it can be a bit difficult for someone with a different idea. But in the end, it is still possible, and if you have valid arguments for a different approach, then it’s a very good idea to have it discussed.

“if someone makes a wrong edit, don't tell them how wrong they are, but talk with them” — This is pretty much the main theme from the comments on reddit. As it turned out, the average wiki editor is very unfriendly to new editors. And I totally agree that this has has to change! I hope that some of the people who showed a more hostile behavior before noticed the ongoing discussion and improve, and I (and others) will also more closely look at how new editors are being treated. Of course we can’t be everywhere at any time, so if you notice such a situation, please do not hesitate and point it out, so we can all learn to improve. poke | talk 14:13, 13 June 2013 (UTC)

We have Personal conduct on Guild Wars 2 Wiki:Practices and processes, but it's pretty brief and could use some examples. We can elaborate more with how to approach and resolve conflicts with other users, as well as approaching admins. It's very daunting for a new user to find out who made a change, how to get to their talk page or discussion page, where to post it, how to present their argument, and how to resolve the issue. As well as how experienced users should respond and deal with new users. Many times people don't understand that their contributions don't disappear and they can do something about it. And that talk pages aren't battlefields where you must stand your ground. It's spread across in wording on the help pages and such, but for my part, I have to search through and pick it out. For example, the wiki having the ideology of no policies completely flew over my head until Ishmael pointed it out. There should be some ways to decrease the gulf between being an "editor" and a "contributor".--Relyk ~ talk < 14:52, 13 June 2013 (UTC)

Hey Poke and Relyk. Thanks for restoring my faith in a possible good future for the wiki. Let me point out straight away that I know my english is crappy. I will never will make any fuss bout someone who is a native speaker or atleast better, to correct me on the content pages. This is however a talk page, and my point indeed is the way people who are 'just an IP' (or a new account) are being treated. The first experience with the community makes an important expression. The way people are discussing things here and are treating each other is the thing thats stopping me from making an account. Maybe something usefull. My native tongue is dutch. When I made my first edit on the dutch wikipedia I got a welcome message on my ip's talk page thanking me for my first contribution and some general tips. I suspect this was done automaticly by a bot, but it made me feel appreciated and it showed that my contribution was noted. A translation of the message can be found here. It helps people finding there way to resources, gives a nice first impression and guides them to the Helper program 195.240.63.18 17:19, 13 June 2013 (UTC)

If my memory serves right, those welcoming messages, especially automated ones, were given up on over time because users didn't like them much. IPs also change over time, depending on the user which might confuse anonymous editors who use an IP which was previously shared by someone else. However, I think something like that could be implemented on those site notification banners permanently (which currently informs of reddit thread discussion as well as generally encouraging visitors to participate). Perhaps include something similiar to the top banner which appears on GW2W:HELPERS page to those notifications? Mediggo (talk) 17:34, 13 June 2013 (UTC)

We had welcome messages in the past (on GWW), and they were often a reason why people left the wiki frustratedly. So instead, we just stopped welcoming every new user explicitely. Instead we direct new users to Guild Wars 2 Wiki:Welcome to the wiki after the account creation. Unfortunately we cannot really do that for anonymous users. The welcome page should ideally provide all the information new users need (and further tell them where to get more help). poke | talk 17:37, 13 June 2013 (UTC)

That being said, if you see a new (or old!) editor doing something awesome, reach out to them and let them know they're being awesome. One of our most prolific editors on ye olde GuildWiki started out as an anonymous editor whose contributions I praised pretty much on a whim. It really does work.

18:56, 13 June 2013 (UTC)

welcome notes for new users

so maybe this is something we can change consensus on? I wasn't apart of gw1w when this was on there so I can't refer to those discussions. maybe we could have a discussion on this wiki about them seeing as this is a new community and new game.- Zesbeer 21:19, 13 June 2013 (UTC)

I think it's a discussion worth having, but I don't think this is the right place to do it- everyone likely to contribute here has already been editing the wiki for a while, and our stance on welcome notes is probably different from new users who would actually benefit from them. This might be something for reddit or the official forums. Can reddit do polls or whatever?

21:21, 13 June 2013 (UTC)

that's why I made this a sub section of this discussion. I just don't think we should continue to do something just because that's what we decided to do on guild wars 1 wiki.-

Zesbeer 21:25, 13 June 2013 (UTC)

Maybe we should have a discussion on Guild Wars 2 Wiki talk:Welcome to the wiki on the general topic on how to welcome new users; how to improve the welcome page, what resources to give them, and what kind of messages are appropriate. I don’t think having another discussion on the community portal helps that much. poke | talk 21:46, 13 June 2013 (UTC)

How to document instances

Escort the Consortium dolyak to the ship takes place in its own instance. The instance itself does not have its own name, but in this case this single event runs through all of the instance (plus some talking at the beginning of the instance and at the end which takes part outside of the event). So here I just put all the instance information on the event page. How are we going to document such instances though? poke | talk 20:44, 4 June 2013 (UTC)

Escort the Consortium dolyak to the ship (instance) seems suitable.

20:51, 4 June 2013 (UTC)

But it’s not really guaranteed that all instances will have one—and only one—event going on from which we can use the name. poke | talk 21:06, 4 June 2013 (UTC)

For Flame and Frost, I generally used the name of the achievement it was associated with (since they use achievements to track these things), with additional input from the mouse-over name of the event star at the entrance (see Rox: Avenger of the Dispossessed and Braham: Avenger of the Dispossessed...Avenger of the Dispossessed is the achievement name, but I added the names in front for the article since the mouseover on the entrance had them). Unless there's a situation where this doesn't work, perhaps we can just go that route. I haven't been in-game to see if this works the same way. I preferred this way because it made it really easy to link it up with other pages, instead of just having some "random" event name. Vahkris (talk) 21:34, 4 June 2013 (UTC)

In this case the star just says “Living Story”… :/ Using the achievement name would work I guess. poke | talk 21:49, 4 June 2013 (UTC)

Using the achievement name for the instance is the best option we have.--Relyk ~ talk < 03:20, 5 June 2013 (UTC)

(Reset indent) Well, the topic of naming of instances/narrative steps was brought up again over here, I directed it over here to continue discussion. We should set a straightforward method of naming instances. Should it be the instance name, then the achievement if one doesn't exist? Just the achievement name? Vahkris (talk) 20:05, 19 June 2013 (UTC)

The Dead End is an actual instance area. The personal storyline are also such instances, but we document them with their own infobox instead of the location infobox. Seeing as you can enter the instance after completing the Hard Boiled achievement, we can use the Hard Boiled achievement for the name of the Living Story mission and The Dead End (instance) for the location. We will need a note about using Hard Boiled for the name of the mission due to The Dead End being a poi and instance area.--Relyk ~ talk < 21:07, 19 June 2013 (UTC)

That makes sense. The discussion came up more because of the previous mission, Memorials on the Pyre, which is entirely linked to the achievement Ceremony and Acrimony and has no base instance (it's Lion's Arch). I'm looking at the Scene of the Crime piece, and it may actually use the same instance as Memorials, but since there's steps to do outside of that instance we currently have the page named Every Piece Matters, which is the achievement. It does seem at least a little inconsistent, which we probably should be trying to maintain. As far as I'm concerned either name works (Memorials on the Pyre, which is the instance label, or Ceremony and Acrimony, which is the achievement), but for consistency sake it's probably best we try to use the achievement at all times for these Living Story missions unless there's none associated with it. Anyone have any thoughts? Vahkris (talk) 21:23, 19 June 2013 (UTC)

Standardized Acquisition Section

We currently start to utilize Properties like Property:Drops item oder Property:Contains item so I would like to propose a standardized Acquisition Section as follow:

==Acquisition==
;Dropped by
{{Dropped by}}

;Contained in
{{Contained in}}

;Sold by
{{Sold by}}

;Other
*Methode #1

We basiclly would only need to edit the 'Other' section. Dropped by, Contained in and whatever we want to add can display a default text when there is no means of aquireing an item on this way. I think that would minimize the work in the long run. - Yandere 11:30, 11 June 2013 (UTC)

seems a good idea. --Claret (talk) 11:42, 11 June 2013 (UTC)

One issue this will raise again is what happens when there currently is no known acquisition method for one of those mini sections? Similar discussion here. poke | talk 16:10, 11 June 2013 (UTC)

Since the templates would create a text which basiclly states the 'this item can't be looted' for example. I would argue that this a a valuable information. You not for example that magic find will not help etc. Should this change however we would not need to update the article because the query would that find a drop and would update itself. You could however make an acquisition template which would display a certain section, when it is applicable and not display the section, when it is not applicable. Either way, we could standadize the currenty mess, and save us a lot of work. - Yandere

16:20, 11 June 2013 (UTC)