Guild Wars 2 Wiki:Community portal

From Guild Wars 2 Wiki
Jump to: navigation, search

Community Portal

Lost in a sea of projects, formats, and debates? Look no further! These are the current hot topics, and you can find previous topics here.

To begin a new topic on this page, use the "+" button at the top of the page.

If logged in, you can also add this page to your watchlist to track any changes and stay on top of things!

Newsletter of the week[edit]

This newsletter is maintained on User:Relyk/Wiki Newsletter and might not objectively reflect what happened on the wiki.

  • Some discussion on Armory embeds aka the wiki is too big.
  • Flashpoint is released. Time to document all the things and nuke the Recent Change log.
  • Template:Temporary is now being used just for seasonal/holiday thing and not for historical content anymore. Craziness.
  • You can now edit and create pages that have "&" in them.

Event Rewards Templates[edit]

While I was adding rewards for defeating bosses in the Nightmare Fractal challenge mode, it came up that the rewards do not come from the bosses themselves, but rather are given out as event rewards (from completing the event objectives). Documenting the rewards for these events required updating both the fractal page in addition to the individual item's acquisition section. This pattern extends to many of the event rewards in HoT maps, where the drop itself may list the events that reward it, but the event itself does not mention the drop (even if it is guaranteed). This seems like a gap in the wiki templates/properties and I'd like the community's thoughts on my proposal.

Create 2 new templates for event rewards/bouncy chests that you don't gain from rummaging around in the still-warm corpses of your enemies
  • rewards to specify what items are rewarded by an event(see Template:Drops):
    "This event rewards this item."
    • {{rewards|Chunk of the Solid Ocean}}
    • {{rewards|Chunk of the Solid Ocean}} (1-2)
    "This event objective rewards this item."
    • {{rewards|Chunk of the Solid Ocean|Defeat Siax the Corrupted}}
    • {{rewards|item=Chunk of the Solid Ocean|objective=Defeat Siax the Corrupted|name=Chunk}}
    Possible example:
  • rewarded by to list what events reward this item (see Template:Dropped by):
    "This is the list of events that reward this item."
    • {{rewarded by}}
    Possible example. I'm not sure what the best format would be, though:
Examples of Usage
  • rewards
    • Personal story rewards, e.g., Roots of Terror
    • Event rewards, e.g., Against the Chak Gerent meta-event, various other HoT events with guaranteed (or randomized) rewards
    • Event Objective rewards, e.g.,
      • The bosses in the Nightmare Fractal challenge mode do not drop loot directly, instead you get bouncy chests as "Event rewards" for completing the objective associated with the boss.
      • Spirit Woods (where such chests are omitted entirely).
  • rewarded by

--Floodbars (talk) 05:54, 23 December 2016 (UTC)

We don't have a template for bonus chests yet, but those gives a random item. The map meta reward is based on tier. The meta event progression rewards are more tied to the dynamic event being part of the meta event, rather than the event itself. The Story Journal stuff is covered by {{reward}} (old, bad name). The problem there is the reward is sometimes dependent on profession and the "pick-one" variation in the reward.
I'd hold off on lookup templates until we have a clear format for how the rewards are presented and where to put them. Seems more likely that we'll create a template for each reward type and at least store the reward item and reward type for presentation.--Relyk ~ talk < 07:10, 23 December 2016 (UTC)

Recent change to effect-based templates[edit]

I don't know hat has happened for sure, templates such as Crippled 40px.png Crippled, Bleeding 40px.png Bleeding, etc. used to support an optional parameter to change the wording while keeping the icon (i.e. {{crippled|cripples}} would say cripples). There are examples of previous use of this convention like here. As a result, I must use {{effect icon|crippled}}[[crippled|cripples]] for editing combat abilities sections of NPCs, which is extremely long. However, I know now that it was not a result of changes to the specific templates, but something that affects the wiki as a whole. I'm unsure as to what it could be, so, if possible, please offer some insight as to why this is happening. Sythe 02:36, 3 January 2017 (UTC)

Articles shouldn't be using the templates anywhere in prose.--Relyk ~ talk < 05:00, 3 January 2017 (UTC)
I'm afraid I don't understand what you mean. Could you elaborate please? Sythe 15:58, 3 January 2017 (UTC)
I believe Relyk means that when it's used, it should solely be in cases where you'd use the word "crippled" rather than "cripples" - e.g., "this applies crippled" rather than "this cripples" - or in list of conditions. Basically, there should be no need to ever type {{crippled|cripples}}. If I'm understanding Relyk right. Konig (talk) 16:59, 3 January 2017 (UTC)
Yeah, when there is text like “Using this skill causes a bleeding, just use normal links like that to keep up the reading flow. Those templates are mostly meant for things outside of text like a list of effects a skill could have. poke | talk 17:31, 3 January 2017 (UTC)
Ah, I see. I was attempting to follow previous conventions used on the wiki as examples, i.e. Jungle Tendril#Combat abilities under abilities. From now on I'll follow your recommendations, thanks! Sythe 17:54, 3 January 2017 (UTC)
You can largely thank User:Louise for doing that to the ability section of many NPCs (and many others followed suit), but as you can see... the templates aren't meant to be used in such a fashion. I fixed that particular article since I noticed other things wrong with it, as it is now is how I, personally at least, think articles should be for that template use. Konig (talk) 19:58, 3 January 2017 (UTC)

Story Instance Map[edit]

Was pondering the idea of including the map of the instances for stories/story instances. Couldn't hurt to have I was thinking, and I have at least one HoT story map(The Jungle Provides) that indicates where certain achievements start/the start is found I think. - Doodleplex 01:25, 7 January 2017 (UTC)

Coordinates on the wiki[edit]

Hello guys. {{Infobox map}} has been up for a few weeks now, and so far I'm pretty pleased with how it's turned out. I'm now thinking about adding coordinates to the following:

  1. Locations: I'm thinking about adding the coordinates from the API to Cities, Zones (not areas at the moment), Heart NPCs (they're in the api already) and probably Points of Interest. This will be "easy".
  2. Hero challenges (related to the above): There isn't currently a neat way to pick up all of the hero challenges pages (where context = Events, NPCs, and Objects) with one semantic query, which I think should be possible. I've composed a manual list of the pages here: User:Chieftain_Alex/sandbox2&oldid=1350395. I'm not sure which direction to go. Option A: We could just stick a manual category at the bottom of the page, such as "category:hero challenges", and then move the current content of that category to "Category:Hero challenge events" (since that's what they are). Option B: Alternatively we could add a parameter to all three infoboxes along the lines of "hero challenge = y" (and only use that for challenges with map markers). I'm open to other suggestions.

Side note: there's also the complication that multiple hero challenges share one page, e.g. Statue of Melandru (hero challenge) has four on one page.

(And yeah, eventually I want to be able to give two [x,y] pairs to a query, and it'll tell me exactly what's inside the bounds.) -Chieftain AlexUser Chieftain Alex sig.png 21:53, 13 January 2017 (UTC)

Round two:
  • I split all the shared hero challenge pages to be one page each. This simplifies maps and dialogue. I've updated all links too afaik.
  • I chose to move "Category:Hero challenge NPCs" and "Category:Hero challenge objects" to Category:Hero challenges since the initiators for the challenge encompass everything (i.e. the total of that category should in theory be the same as the ingame total for Tyria+The Mists = roughly 253). Events are now to be found in Category:Hero challenge events. I've added the coordinates to all hero challenge NPCs and objects, but let it default to jpeg maps if available and left coordinate maps as a fallback.
Hearts and points of interest are next on my list. -Chieftain AlexUser Chieftain Alex sig.png 19:48, 4 March 2017 (UTC)
Was wondering why the hero challenge pages got split... Konig (talk) 21:00, 4 March 2017 (UTC)
Should I add event coordinates to the wiki too? -Chieftain AlexUser Chieftain Alex sig.png 22:35, 9 March 2017 (UTC)
Yes. - Doodleplex 22:39, 9 March 2017 (UTC)
Events are weird - I know how to convert the "center": [ -45685.2, -13819.6, -1113 ] to coordinates = [x,y], but I have no idea what we want to do with the sphere/cylinder/poly types + their radius. I'm thinking I should still add the X/Y if there's a direct page match. -Chieftain AlexUser Chieftain Alex sig.png 23:37, 9 March 2017 (UTC)
Okay 1900 events now have coordinates added to their infoboxes. There are about 2000 historical events in the event_details API (e.g. Mordrem invasion, Scarlet, and a further 900 events which either aren't documented or have duplicate names (e.g. rift events, an event for each rally point in verdant brink, etc) - too many to manually sort out.
The tango icons look kind of cruddy. We could do with the ingame icons from the dat. -Chieftain AlexUser Chieftain Alex sig.png 13:04, 12 March 2017 (UTC)
Noticed two things so far: First, it appears if a .jpg map was uploaded already, like for Help U.N.I.T. find and destroy the Inquest, the coordinates do not show up. Second, the coordinates a great for events that are stationary in one place but are absolutely terrible an escort type event where they go from A to B, as I have no idea if that circle is the starting point, the end point, etc. (edit) Also coordinates don't show up at all for meta events. - Doodleplex 19:25, 13 March 2017 (UTC)

No Periods. Period?[edit]

I tried asking this before, but I think it got missed. Similar to how we don't use period in event names, can we do the same for items and effects that have periods in them such as "Ponder the Cobiah Marriner Statue." and "You can not use this skill right now." as it's much more readable without the period. - Doodleplex 22:09, 23 February 2017 (UTC)

Nah, I think we should leave those as is. The difference is that events with periods are much more common than items are. It's in the api, it's in the game, and it should be listed on the wiki with a period as well. Of course, an argument could be made that we should also put periods on events to reflect their in-game nature, but that's a discussion for another day. —Ventriloquist 09:18, 24 February 2017 (UTC)
If keeping them does no harm (i.e. doesn't affect look-ups), then there's no need to go and remove the ones with periods. G R E E N E R 06:23, 4 March 2017 (UTC)
Alright, I just think it looks a bit weird but if that's what seems to be accepted then I'll not poke it. - Doodleplex 06:50, 4 March 2017 (UTC)
I'd rather remove the periods, the main reason being we don't quote wikilinks and it looks bad at the end of a sentence. The other reason being that having to add the period when searching is unnatural for people. It's much easier to add the period in the alt text if needed, which is moreso easier for less common pages like Vent noted.--Relyk ~ talk < 15:17, 12 March 2017 (UTC)
To be fair most people don't type things out that far to get to the period, but I do like the above idea to just add it as alt text. - Doodleplex 19:28, 13 March 2017 (UTC)
Looking from URL viewpoint, the period make stuff confusing. E.g. some softwares like chat and such autoconvert URLs to links and most of them ignore the period as it not being part of the URL, even the official forum itself does that. In fact, the wiki itself does that, if I just put in plan text (check the source to see it) it leaves the period out of the link destination. --Txon Atana - (talk) 23:41, 6 May 2017 (UTC)

Request for Adminship: Doodleplex[edit]

RFA page has been created at Guild Wars 2 Wiki:Requests for adminship/Doodleplex. G R E E N E R 22:15, 15 March 2017 (UTC)

External links from item infoboxes[edit]

I think we should consider reviewing the links we provide at the moment. Example: Elonian Leather Square provides links to the following sites:

  • GW2Shinies
  • GW2Spidy
  • GW2TP

Also, are there any better options? (as example, anything with a recipe to make it could instead link to gw2efficiency) -Chieftain AlexUser Chieftain Alex sig.png 21:26, 16 March 2017 (UTC)

I wouldn't mind seeing it appear under "Chat link" in the {{recipe}} template, if possible. G R E E N E R 22:05, 16 March 2017 (UTC)

The ampersand symbol[edit]

I was pondering the other day, since the ampersand or "&" symbol is currently not working right, I was wondering if for the pages that currently have them should be redirected to pages that don't have it in the name so that everybody, not just the few of us with bots, can edit/create them. Or basically, redirect anything with "PR&T" and "R&D" to "PRT" and "RD" respectively and stick the tag for technical restrictions on top. The only trick I don't know though would be how to create redirects for the pages that haven't been made yet (which is pretty much just the NPCs in Jeztar Fall), would creating a page and then moving it to the correct name (with the redirect already on the page to avoid trying to edit after moving it issues) work? I don't want to break anything hence why I haven't tried that idea myself. - Doodleplex 22:38, 27 March 2017 (UTC)

Issues with ampersand and a few other symbols were supposed to be fixed around January with the update to the wiki backend. Got any examples?--Relyk ~ talk < 23:33, 27 March 2017 (UTC)
Examples of it not working? Yeah, tried to make "PR&T Mini Ooze Projection" and got the "PR" page which Alex deleted. - Doodleplex 23:36, 27 March 2017 (UTC)
If we can make a more robust version of
// Encode wiki links that might break, e.g. ampersands.
function encodeWikiElements(selector, attribute) {
  $(selector).each(function (i, element){
    var m = $(this).attr(attribute).match(/^(\/index\.php\?title=)(.*?)(&curid=.*|&action=.*)$/);
    if ((m) && ( $(this).attr(attribute).search('%') === -1) ) { $(this).attr(attribute, m[1] + encodeURIComponent(m[2]) + m[3]); }
we could stick it in the common.js -Chieftain AlexUser Chieftain Alex sig.png 00:17, 28 March 2017 (UTC)
breaks on rollback links at the moment. -Chieftain AlexUser Chieftain Alex sig.png 00:27, 28 March 2017 (UTC)

SAB request[edit]

I'm posting this here because I don't know if there is a more appropriate place to make requests. One thing currently lacking in each of the SAB level articles is a clear organization of things by category, by which I mean the locations of locked chests and destructible furniture counts, things which are relevant to daily and other achievements, but which are not terribly accessible as such when scattered throughout the text of a full walkthrough. If someone could please design an organizational structure to highlight this information - as a starting point you could consider something similar to what is already done for digging spots. Thanks. 17:29, 5 April 2017 (UTC)

You may find this helpful in the interim. SarielV 20 x 20px 18:22, 5 April 2017 (UTC)
I created the above linked page to be a general guide for what you need to do for the dailies, since the walkthroughs on the Zone page are intended to guide players to obtain all of the bauble/hidden shop achievements as well as guide them to the end of the zone. The digging spots are a separate section on the zone page since they aren't required for either zone completion or any of the previous achievements before the dailies came around, but were relevant to the zone. - Doodleplex 23:17, 5 April 2017 (UTC)
Yes, guide page works fine here.--Relyk ~ talk < 16:09, 6 April 2017 (UTC)

On the Community, Administrators, and Reconfirmations[edit]

moved from Guild Wars 2 Wiki talk:Requests for adminship/Doodleplex#On the Community, Administrators, and Reconfirmations
Since we're now conducting human experiments, are we going to have reconfirmations for all current administrators as well? Might be a good chance to gather some feedback concerning what the community thinks of and expects from administrators, thus aid in fixing possible issues — all the while establishing some contemporary groundwork in terms of adminship which might ease the processes of possible future RFAs and clarify the actual role of an administrator further. It would also help in identifying whether the lacking activity of this and the past RFA was user-related or the result of general wiki lethargy. I am actually only sharing this suggestion since, based on my evaluations, none of the current active administrators are likely to lose their adminship over a reconfirmation. Thoughts? User Incarnazeus Signature.pngtalk 19:33, 20 April 2017 (UTC)
Well, having a reconfirmation for Doodle already may not necessarily be the most useful thing in the world without specific reason, but if you (the general you, whoever) wanted to call for reconfirmations on the other admins (me included), that's certainly a thing you're allowed to do. Actually I don't think we have a particular process for calling for reconfirmations, considering the only reconfirmations we've had were the initial round of em back in 2012, but I'm sure we could stumble our way through something. That being said, I think if your main goal is clarification of the admin role without any particular doubts in the current admin team, perhaps a discussion on Guild Wars 2 Wiki talk:Requests for adminship or Guild Wars 2 Wiki talk:Practices and processes would be more in order, either first or instead. - Tanetris (talk) 00:48, 21 April 2017 (UTC)

(Reset indent) You are right, having a reconfirmation for Doodle so soon would make little to no sense, particularly since she already received her, although possibly a bit lacking, feedback. That should suffice for the next few years.
When I suggested reconfirmations I meant ones for the already existent administrators. I am still more inclined to have reconfirmations for all the long-standing administrators instead of just clarifying the role of an administrator, since it would be a valuable experience for all participants.
This is mostly because:

The position as an administrator should not be a secure one, let alone a "title for life". Since most people, particularly new or less committed individuals or even mere passers-by, might not know about the possibility to instigate a reconfirmation, it makes more sense to routinely reconfirm all administrators once in a while (I am aware of the suspended policy proposal that never made it through).

As for the reasons why, there are several, though I shall present the three major ones.

The community as a whole is in constant movement. People come, people go. The ones who voted for you (here and in the following as "general" you; not addressing anyone specifically) when you were first nominated are most likely no longer present. A reconfirmation will show you how you stand with the community in its current state. You will be able to collect (ideally constructive and meaningful) feedback. Positive as well as negative. The former covering the need for praise and appreciation, both invaluable for increasing and/or ensuring productivity and enthusiasm. Personally speaking for a moment; I find acknowledgement and praise are certainly good means to encourage me to try to improve myself further. I would like to believe this applies to most humans, however, I am not claiming that it does. Concerning the good of negative feedback, it should help pointing out areas where some kind of improvement of your admin-self and/or the way you operate is necessary. Lacks and needs may make themselves present, demanding some kind of action — acknowledging that there are lacks would certainly be a step in the right direction already.

Further, reconfirmations serve the purpose of engaging the community. Transparency is ensured. Not only this, it represents the belief that every single member of the wiki community has a say in wiki-related matters. Regardless of what kind of user you are. This is good for the community and should help it grow (closer). In addition, it helps coming to a consensus regarding how adminship should be through the collective of different opinions and persons. Likewise, awareness is raised. There are individuals who are not aware of how this wiki is run (the general belief is still that the information mysteriously appears out of thin air or that ArenaNet or some other single person manages it; i.e., at one time one person asked me to my horror whether I ran the wiki on my own), or that there are administrators, and even if they know that there are, they do not know who actually is one. Yes, we have the list of currently (in-)active administrators. Its usefulness is debatable. How should these people then know they can help administering the administrators? I was sceptical of having a site notice for RFAs at first, but it seemed to have helped. However, it would further aid if we had some sort of guideline that helps (less) experienced editors and the target audience to make the most of their right to vote.

Lastly, reconfirmations help us weeding out the inactive administrators. Some might even come to the realisation on their own that it might be a better idea to step down if they lack the time or commitment they had when they just started out, instead of being a "ghost" admin. Some might need the input of the current community to come to this realisation or be confronted with the reality. Along the way the red names might turn into blue ones, and the list of administrators might grow, particularly since, ideally, the benefits of having reconfirmations come into play and pay off.

I do not wish to call for reconfirmations without prior communication and consent. This is an attempt to turn a new leaf, not to stir up drama and offend individuals. If we are going for reconfirmations, we should keep in mind to try to cater to all kinds of participants. This means that the candidate statements should be a bit more elaborate than: "Hey, I've been doing this for x years, ya'll cool and stuff, let me at it again" but instead briefly state who you are, what you did, for how long you did it, what your domains of expertise are, what you might have noticed about yourself that you want to improve, and what you are going to do or continue to do for the community if they decide to keep you. During the reconfirmations the candidates should try to engage with the ones voting; that means try to answer questions or resolve possible issues and thus show their commitment and interest in this.

This covers what I wanted to convey to a degree. Are there further thoughts, comments, concerns, questions, what have you? User Incarnazeus Signature.pngtalk 12:11, 21 April 2017 (UTC)

I think you brought up some good points worth discussing. Not an overhaul, but simply a reconfirming of where we are and what the community would like. Could we move the above to a more appropriate page? G R E E N E R 15:12, 21 April 2017 (UTC)
Sure. Guild Wars 2 Wiki:Community portal or Guild Wars 2 Wiki talk:Requests for adminship? User Incarnazeus Signature.pngtalk 15:52, 21 April 2017 (UTC)
I'm interested to see what the response is, so I'm inclined to have your above post copied over to the Community Portal. G R E E N E R 15:59, 21 April 2017 (UTC)
By all means carry out reconfirmations for everyone. I'm sure the majority of contributors expect some level of continuous validation for sysop users. -Chieftain AlexUser Chieftain Alex sig.png 17:19, 21 April 2017 (UTC)
"The position as an administrator should not be a secure one, let alone a "title for life". ... it makes more sense to routinely reconfirm all administrators once in a while"
You're going to give some of the really old hands flashbacks to the GW1W bcrat elections, which were kind of a nightmare. For reference, there were 3 bcrat seats, each with a 6-month term, staggered, and elections took a month, which meant 1-month election, 1 month off, 1-month election, 1 month off, repeat for all eternity (except not for all eternity, as the community eventually got sick of it).
That being said, it's been 5 years since most of the admin team has had reconfirmations (3 years since the RFAs for Alex and Vent), so a round of reconfirmations every 5 years in addition to 'as needed' is probably not too onerous.
Opinions are probably always going to be mixed on whether an inactive admin should remain an admin. The age-old argument goes that if we trusted someone with the admin tools then, there's no reason they aren't still trustworthy with the admin tools, and we lose nothing by letting them keep it in case they happen to come back and see something that needs adminning. By the same token, Infinite for example quit the wiki 4 years ago, so there is probably not a great deal of value keeping him on the sysop list. And now I'm worried about Gares realizing I haven't heard from him since an e-mail a year ago... Gonna be looking into that. But that aside.
The point I was trying to go for was that I personally don't mind going up for reconfirmation, but let's not go crazy with required reconfirmations for no reason every couple months or anything like that. - Tanetris (talk) 23:28, 22 April 2017 (UTC)
My hiatus from the GW1W admin team lasted a few years, so there's some support for the age-old argument. And please, not that 6-month cycle again...
I don't want to see anything which results in a "Keep this admin!" vs. "Kick them out!" mentality, either. Perhaps a softer, "Hi, my name is ______. Here's my role on the wiki. How do you feel about this role, or my performance in it so far? Is there anything you'd like to see changed or improved on my part?" I.e. a means of gathering feedback. I believe that if the feedback were somehow overwhelmingly negative, then we could talk about shifting some people out of their current role. G R E E N E R 00:18, 23 April 2017 (UTC)
I can understand having breaks from, or hiatus from the wiki, but at some point it gets too long imo. There are some admins that I don't recall ever seeing active (even in editing) since I have been here. To me it seems odd that such people would still be considered Admins. To me if there is no trace of editing or admin-ing for a lengthy time, the title should be revoked. Now possibly those people who were once admin could always do a fast-track RFA to get it back if they wanted to, but having an admin list which only has 3-4 of 9 admins appearing in some sort of regular fashion seems strange to me.
I get that one trusted with admin will be trusted as admin for a long time but after a while it seems like the name is just there to collect dust and the title 'admin' becomes just an empty statement associated with them (at least for me who has never even seen them at work).
I personally don't know of anywhere else that holds things like this, any group I've seen with a long inactive admin/mod has eventually had the rights stripped (possibly to be re-given later if needed). It doesn't do any harm mind you, just seems... odd. -Darqam 01:20, 23 April 2017 (UTC)
I fully agree with Darqam concerning the question of meaningfulness of retaining sysop rights after prolonged absence and/or inactivity. Sure, an inactive administrator has been elected at one point, and their trustworthiness is out of question (although if I remember correctly I think I did stumble upon some discussions about someone who, after coming back after a longer hiatus, acted a little wilfully if not out of line), but it shines a bad light on the wiki if we are wishy-washy when it comes to removing people that no longer make an effective use of the rights they earned because of their initial qualifications. Think of it along the lines of "Do, ut des" (I give that you may give). If you cannot or will not make use of the privileges granted, you should not have them — or rather, you do not need them. Period. A bit of strictness, but more importantly consistency (both achieved through regular reconfirmations, and the related consequence that sysop rights will be revoked if you are inactive for an ungodly amount of time), will enhance the position as an administrator and render it somewhat more "important" and "relevant" — not just an empty title or "statement" as Darqam points out. It enforces your position if you have to "prove" yourself occasionally. People will respect you a lot more.
Regarding the recurrence of reconfirmations, I concur that having them every six months is insane, even every two years (as the failed policy proposal proposed) is too often. Every five years might be too infrequent though. A lot can change in five years, and people are most likely to forget along the way. I would suggest reconfirmations every three years, since it seems like a fair amount of time to gather enough feedback and if we assume that the average core editor might be invested for three years before moving on, we have a good mix of old and new community members to feedback the administrator adequately. A bout should not last longer than two weeks with an additional week if no consensus can be reached. A month seems awfully long. Short bouts can only work if we advertise enough though. Apart from a site notice, threads on reddit and the forums and info posts via the official social media channels might be in order. These advertisements would need to cover the meaning of reconfirmations, the rights of editors and target audience, and the general schedule though. As Greener said, reconfirmations should not end up in a 'Yay'-or-'Nay'-Battle, candidates and participants need to be briefed accordingly to ensure the purpose of gathering feedback (and introducing the administrator at the same time to people less familiar with the wiki) is fulfilled. User Incarnazeus Signature.pngtalk 12:34, 23 April 2017 (UTC)
I agree with what's been said. This could definitely serve as a way of gathering feedback on what we, as sysops, are doing - how it's perceived, how we can improve and such. I wholeheartedly support the idea. —Ventriloquist 13:30, 23 April 2017 (UTC)

Temporary, Historical, etc[edit]

I'd like to make how we mark where something came from and it's status a lot simpler and cleaner. Currently NPC/object/event that were part of past releases currently can only be shown as such by having a {{temporary|Release name}} on top. Of those that use that and aren't reoccurring seasonal content, a good portion of those infobox status were never edited to mark they were historical. However, if in NPC/object/event was marked as historical, such as Champion Toxic Wurm Queen, they have two banners on the top and are categorized twice on the bottom as being both Historical and Temporary content, which can be confusing and redundant. Now that we have Template:Infobox release, I think we should use that to mark which past release the page's content came from and have the release template categorize if something is historical or not. Additionally, I'd suggest making a template just for release banners so that that Infobox release template could pull from there and not Template:Temporary, so basically the Temporary template can really just be a banner/notice template for seasonal stuff. That way simply sticking the release in the infobox means the status will always be correct, no need to write it in the infobox, it gets put into one category(or so I hope), and the nice banners for past releases still get to be used, ie no double boxes at the top, since the box saying "This content was only available during X Release" is essentially just a prettier historical notice tag. Any thoughts? - Doodleplex 03:45, 26 April 2017 (UTC)

To me temporary implies that the feature will return and historic implies that it’s not coming back. If we can agree on that definition then we can start labeling things properly. Reoccurring events like wintersday and SAB will be temporary and living world season 1 will become historic. J.Tesla (talk) 21:21, 26 April 2017 (UTC)
Good point, and yeah that's what I think as well in regards to the definition of those two words. - Doodleplex 23:36, 27 April 2017 (UTC)
I've mentioned my opinion on this before:
  • I'm not fond of the use of the historical template via infoboxes removing categories (makes it hard to search for Season 1 content; only way to do so is by knowing the name of the content in search box or navigating an ever-growing list of Category:Historical content, since automated lists search via category).
  • Now that Living World content is no longer temporary (the original purpose of the temporary tag being to separate it from purely removed content) I don't think that the temporary template is necessary anymore at all.
  • And I don't see much need for a banner at the top for festival content (simply having a line in infoboxes akin to GWW's Campaign parameter for infoboxes detailing which festival would suffice). It'd also be nice if we can use this or a similar line to include when it was added for Living World content, but I don't think it's entirely necessary; I think just denoting which season or boxed release would be sufficient (so core, Season 1, Season 2, Heart of Thorns, and Season 3 as it stands).
Ultimately, banners are obstructive. They're useful for notice and maintenance templates, but feel unneeded and overplaying for festival or Season 1 content. Konig (talk) 23:48, 27 April 2017 (UTC)
You'd be wrong about the temporary template. It's purpose as a notice template is to mark that some things only have a limited time frame, so yes it is still necessary for at least for seasonal content like Halloween and festivals such as the Super Adventure Festival. If you have some other definition of what is temporary though, then please say so, as that's one of the things we're trying to figure out here. Additionally if we stopped using the release banners for the season 1 content, those pages would still have the historical content banner on top which is larger and bulkier. Simply moving the smaller, slimmer release notice banners to the historical content template(not really sure if that would work though) or a new template and changing the text on them to say "historical" would actually be less obstructive and better at relaying information about why that content no longer is in game. The question remains, should we use the Infobox release template to make tagging historical release stuff easier, is there a better way, or leave it alone? - Doodleplex 02:36, 28 April 2017 (UTC)
The way I see it we end up with two types of page:
  • Historical content that will not return and was only available for a release. This should use status = historical. A sentence at the top of the article would be sufficient to describe which release it was there for. We can add a category for release-only content using the infobox. The temporary template should be removed, resulting in only the historical notice.
  • Currently historical content that will return. Imo this type of page should not use the historical template, and maybe should use the temporary content template. Again we can add a category to group it with similar content.
-Chieftain AlexUser Chieftain Alex sig.png 06:38, 28 April 2017 (UTC)
I was actually thinking about doing the category thing for the season 1 stuff, so good to know I wasn't the only one with that idea, and the Temporary template actually already categorizes the seasonal stuff into the relevant season's category, so that's already a thing heh. Since so far it seems like the generally accepted definition of temporary and historical is how Telsa said it, we can start working on the how to clean this up. Did a little checking, and of the almost 500 pages that use the Temporary template(well a little less, cause I excluded seasonal/SAB stuff that came back), half of the pages that should have been marked as historical, weren't. It would actually be more than half, but during my current quest to fix all of the old dialogue formatting and add locations to NPC pages, I've already gone through a good chunk of historical release NPC/events/objects that only had the temporary tag and marked them as historical. This is more or less why I'm bringing it up, I think if we use the banners we have already, move them to a new template and just tweak them slightly/have them categorize stuff as historical, then set up the release page for the old releases and to use the banners, it would be an easy 1-Step way of leaving a notice at the top and tagging things as historical: just put the release in and the rest is done. I'd love to do the same thing for temporary, but that I'm not sure how that would work code wise. Just for comparison by the way for the historical banners, I did a mockup on my sandbox page.
This in my opinion:

{{User:Doodleplex/Sandbox 7|Last Stand at Southsun}} a lot more appealing on a page than this:
Historical This page contains information about a Guild Wars 2 element, mechanic, or feature that has been removed or replaced.
The information on this page does not apply to the current version of the game or the content is no longer available.

Notes: This content was only available during Last Stand at Southsun.
Text is always changeable. - Doodleplex 22:42, 28 April 2017 (UTC)
I meant the introductory sentence outside of any template at the top of the article. -Chieftain AlexUser Chieftain Alex sig.png 22:51, 28 April 2017 (UTC)
I don’t think Template:Infobox release should set if something is historic or not; I think it should just be for categorising releases and add a link to the page for the release in the infobox somewhere and leave "status =" to set historical or current. My reasoning is that not everything introduced in a historical release is historical. Items stick around and so do some events. I do like the image that is used in the temporary template (especially the version that gets pulled from the release page with the intractable text). It seems a waste not to use that somewhere but sometimes a simple line of text can work better. J.Tesla (talk) 22:43, 29 April 2017 (UTC)


Okay I've added a "status notes" parameter to every infobox (as well as removing the old "historical" parameter). This parameter allows you to pass notes to the historical template. I propose we do something like this to all of the permanently-gone-content. My intention is to only leave the "temporary" template on recurring content (halloween, wintersday, lunar new year, SAB). Everything else would be converted to status=historical, temporary notice removed, a note added inside the infobox using "status notes", and a category added to the bottom of the page.

The picture in the temporary template is nice and all but imo if the content is historical I'm expecting gone-quaggan. -Chieftain AlexUser Chieftain Alex sig.png 21:36, 30 April 2017 (UTC)

Eliminated quite a few pages from the to-do list, some non-recurring stragglers visible on Guild Wars 2 Wiki:Sandbox. -Chieftain AlexUser Chieftain Alex sig.png 22:54, 1 May 2017 (UTC)

API links on skill pages[edit]

What happened to these? They were really useful when I was double checking and fixing coefficients :B -Towelcat (talk) 10:02, 28 April 2017 (UTC)

This happened. You can, however include this on your common.js page (like this). —Nefastu 10:10, 28 April 2017 (UTC)

Bounty system[edit]

I've been wondering this for a while now. Similar to StackExchange's Bounty system: Would it be possible to create a page for bounties that players would like to see completed? I know that Dashface has their specific page for articles needing more information. But say if someone else wanted to see an article completed, then they can award gold/mats/etc. to the person who completes it. Naturally of course this would have to be based on the goodwill of the person posting the bounty, but nevertheless I doubt it would be abused. Sythe 14:17, 29 April 2017 (UTC)

I like this idea. -- Dashface User Dashface.png 06:58, 7 May 2017 (UTC)

GW2Armory Embeds for the wiki[edit]


This is to start a discussion to see if you guys would be interested in using the embed system made available by, see:

Currently being used by and (and a few other smaller sites) - I think it would be pretty neat if it made its way into the wiki.

Let's talk?

Cheers, madou

It's neat, but I don't think the wiki would have a way to use it since this seems aimed at build sites. It would also be way more of a hassle compared to implementing the formatting ourselves since we already have all the information available.--Relyk ~ talk < 00:18, 3 May 2017 (UTC)
Well, I'd like to think its aimed at any site that would like tooltips (or armory characters)! You're not wrong I guess - the main difference here is how the data would be presented - I kind of think having both (hover over icon - see tooltip, click through - see more information) kind of a neat feature. There also was a comment about potentially getting character embeds on user pages (see:, thoughts? Cheers, madou --Madou (talk) 00:28, 3 May 2017 (UTC)
As requested, I'll add my opinion here. Maybe I fail to assess the impact correctly but as Relyk said, we do have all the information you can possibly collect from the API for items, traits and skills (I acknowledge the holes in items where no one has bothered to create an article yet) so it would be a step back to replace this information and redundant to get it additionally. We also do have an interest in keeping the information up to date, not just since the Skill History project. I suggested a character embed on user pages because I think thats the only place where I see only benefits and consider this introduced dependency as negligible. --Soulblydd (talk) 08:01, 3 May 2017 (UTC)
Yeah fair enough - do note though that I'm not saying the tooltips would replace the data, but would just be an additional feature, that any page linking to an item etc could have the icon as an armory tooltip, that you can click on to go to the actual wiki page for said item. But I won't press if you think its not worth it. Let's work on allowing character embeds on user pages then? Anything I can do to help? Fyi there also exists a "custom" embed where any user/character/guild data can be retrieved as an embed, but that still needs work before use in production. --Madou (talk) 09:17, 3 May 2017 (UTC)
Tooltip boxes would only be used for compacting information since we provide information in a tabular format and tables tend to get too large. A tooltip box would be overkill or annoying for most content. This would only apply to specific tables we have and the wiki provides information outside the scope of the embed or what any third party could provide really. We would suffer from content lag due to not being in control of the content, such as the wiki being updated quickly with new content and immediately available but having to wait for the armory site to update.
For user pages, people can do whatever they what with their common.js and wouldn't need wiki support. For the wiki to provide the service, we would need to create and maintain a widget along with the burden of monitoring and securing content from a third party. It's not worth the resources for something that would only be used for user pages and doesn't provide any benefit to the wiki itself.--Relyk ~ talk < 15:48, 3 May 2017 (UTC)
In theory we could do it via a widget for userpages only, but really, as said above, we can generate most of this information locally (we have more stuff documented about gw2 than the gw2 API does). If players really want to use armory, they can visit your site no? -Chieftain AlexUser Chieftain Alex sig.png 16:56, 3 May 2017 (UTC)
As others, I also fail to see a real use case for the wiki. Outside of the user namespace, this does not really seem that useful for this wiki given that we almost never present the information these sheets make available. Furthermore, as a wiki, we depend on being able to link to related articles which these embeds would not support out of the box, not to mention that those mouse overlays are rather terrible for accessibility of the content. I also worry about the duplicated information. If we had such things, they would have to load the data from our wiki content and not some outside source.
And as for use on userpages, I don’t really like the idea of adding such a thing just to allow people to add them to their userpages. I also believe that we might hit the wrong target audience if we had a functionality like that (I remember the Guild namespace on GWW here which mostly attracted people who only cared about their guild page, ignoring all kind of rules etc.).
Anyway, we might be able to build a simple version of this, using wiki content we get through SMW, no? poke | talk 18:30, 3 May 2017 (UTC)
I did trait + skill tooltips on this wiki back in 2015: currently we don't SMW annotate the "facts" bit on skills, traits or food. For food at least we should probably try. -Chieftain AlexUser Chieftain Alex sig.png 19:40, 3 May 2017 (UTC)
We still need to semantic objects for skill facts, which hasn't been completely fleshed out. Ishmael started work on it years ago. I wanted to wait for the skill API so we could start structuring our infoboxes and semantic data to more closely much the game API. Tossing around skill fact objects is going to be similar to recipes so we'll need to be somewhat careful.--Relyk ~ talk < 21:56, 3 May 2017 (UTC)
Tooltips for traits/food/skills would only need a very basic implementation (i.e. no searching required), we could just do a straight dump of the skill fact code unless it adds categories or some property crap... which its bound to. -Chieftain AlexUser Chieftain Alex sig.png 23:06, 3 May 2017 (UTC)

NPC Appearance Table?[edit]

Considering that one of the big ideas of the game is that you can replicate any NPC's appearance that you see in the game (regardless of how well that was actually achieved), I had the idea of creating a new table template to use to add that information to NPC pages. While this would obviously be added rather slowly (because it's a pain in the butt, especially dye colors), having a way to attach this information to NPCs would be a great boon to players. Here's my table idea (using Shining Blade NPCs for this example):

{| {{STDT|npc}}
! Slot !! Appearance !! Dye 1 !! Dye 2 !! Dye 3 !! Dye 4 !
! Head
| {{item icon|Banded Helm}} || {{dye|Sand}} || {{dye|Calfskin}} || n/a || n/a
| {{item icon|Banded Pauldrons}} || {{dye|Sand}} || {{dye|Calfskin}} || n/a || n/a
| {{item icon|Draconic Coat}} || {{dye|Sand}} || {{dye|Camel}} || {{dye|Country Teal}} || n/a
| {{item icon|Banded Gauntlets}} || {{dye|Sand}} || {{dye|Calfskin}} || {{dye|Country Teal}} || n/a
| {{item icon|Banded Legs}} || {{dye|Sand}} || {{dye|Calfskin}} || {{dye|Country Teal}} || n/a
| {{item icon|Banded Greaves}} || {{dye|Sand}} || {{dye|Calfskin}} || n/a || n/a
!Main Hand
| {{item icon|Iron Sword}} || n/a || n/a || n/a || n/a
!Off Hand
| n/a || n/a || n/a || n/a || n/a
Slot Appearance Dye 1 Dye 2 Dye 3 Dye 4 !
Head Banded Helm.png Banded Helm {{dye|Sand}} {{dye|Calfskin}} n/a n/a
Shoulder Banded Pauldrons.png Banded Pauldrons {{dye|Sand}} {{dye|Calfskin}} n/a n/a
Chest Draconic Coat.png Draconic Coat {{dye|Sand}} {{dye|Camel}} {{dye|Country Teal}} n/a
Hands Banded Gauntlets.png Banded Gauntlets {{dye|Sand}} {{dye|Calfskin}} {{dye|Country Teal}} n/a
Legs Banded Legs.png Banded Legs {{dye|Sand}} {{dye|Calfskin}} {{dye|Country Teal}} n/a
Boots Banded Greaves.png Banded Greaves {{dye|Sand}} {{dye|Calfskin}} n/a n/a
Main Hand Iron Sword.png Iron Sword n/a n/a n/a n/a
Off Hand n/a n/a n/a n/a n/a

The big problem currently is that including a dye's name and color preview is, frankly, a pain in the butt. Included in the example I made is the *intuitive* way that it should work, as opposed to

<div style="border: 1px #000000 solid; background-color: #{{{2|D9AB95}}}; width: 18px; height: 18px; display: inline; margin: 1px;">[[File:Blank.png|link={{{1|Peach Ice Dye}}}|17px]]</div> [[{{{1|Peach Ice Dye}}}]]
just to create
Peach Ice Dye. Would that be something implementable if this was accepted?

The big challenge to implementation of this is that, as there's no way to pull a list of dyes that an NPC uses, there's an element of subjectiveness in picking the dyes used; however, I don't see this being too much of a problem, as anyone using the lists other players provide will either be satisfied with "close enough" colors or will find a more accurate color and (hopefully) update the wiki.

Krisalys (talk) 06:06, 15 May 2017 (UTC)

I'm a big fan of the idea of listing the skins. I'm not as convinced of the value of trying to research the dyes, but I'm not opposed to it. -- Dashface User Dashface.png 10:05, 15 May 2017 (UTC)
We had this idea pop up before, and concluded that it's simply too much work. There's over 6000 NPCs that belong to playable races (and a plethora of undocumented ones, too). Sure, a lot of their appearances are repeated, but as it stands, it could be seen as a hefty project that would take months to accomplish. —Ventriloquist 18:35, 15 May 2017 (UTC)
Along with the reasons Vent stated above, there's also the fact that some of the pieces some NPCs wear are not available to the players in game so the table wouldn't be accurate/complete for every NPC, and I feel like dyes could be fought over as which one is the correct. This might not be a bad idea for a User page, but I'm not a fan of the idea in a Main Space article. - Doodleplex 19:11, 15 May 2017 (UTC)
I wasn't thinking of it in terms of "Let's try to make this exhaustive", and more "this would be a nice thing for people to be able to add while figuring it out themselves". As I acknowledged, the dyes would be a source of contention, sure, but they're also the part that's difficult to figure out, as armor tends to be fairly easy unless it's one of those "Thaaaaat's not in the game. uhhhh" situations. Having a single resource that's even just *helpful* for it would be a great addition to the available templates, and to stave off *too* many "well you're obviously dumb" arguments, a disclaimer could be added to the bottom of the table that's just "Dyes listed are best guesses and may not be correct". I can see its primary use being for things like guards, priests/priestesses of the Gods, and so on, rather than being super-extensively added to every last NPC (though I might do a decent portion of that depending on how bored I get..... not that I have a problem with constantly making new outfits). Also, the dye name & color preview thing feels like its own valid issue; should I maybe split that off into its own suggestion? The preceding unsigned comment was added by Krisalys (talk) at 20:44, 15 May 2017 (UTC).
The way NPC composite/racial model info is stored in the dat doesn't specify an actual color id only the raw data (brightness, contrast, etc). So there may or may not be an actual dye available in game that is an exact match of an NPCs color. And of course, as already mentioned, their actual armor pieces may or may not be an obtainable skin id (or even have a skin id) MadMaxx (talk) 22:16, 15 May 2017 (UTC)
I just don't consider the wiki a place meant for such information. At best it could be sorted under trivia, but even that is pushing it, imo. Also, even if we were to implement it, we'd have to be consistent and follow the formatting guidelines, but as it stands, I'm against the idea. —Ventriloquist 22:22, 15 May 2017 (UTC)
I don't think we would ever do this because there are very, very few people interested in tabular description of an NPC appearance if they're on the NPC page. The only time I've seen us note appearance is for the weapons and armor of significant NPC characters who tend to have unique equipment. If we did want to, we would create a data dump page rather than add to individual NPC pages.--Relyk ~ talk < 22:47, 15 May 2017 (UTC)