Guild Wars 2 Wiki talk:Community portal/Archive 14

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.

Story Instance Map

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. - Do_odleplex 01:25, 7 January 2017 (UTC)

That sounds like a good idea; the infoboxes support maps so the only thing stopping you would be having already done the achievement. -Chieftain Alex

21:14, 11 July 2017 (UTC)

Release-related content and categories

I've been looking at the current state of categorization with regards to release-related content; in particular, HoT and Living World Seasons 2 and 3. I'd begun by adding {{Living World Season 3 content}} to a few dozen Flashpoint articles, but I quickly realised two things:

Category:Living World Season 3 content was quickly bloating into something monstrous and I'd only barely made a start on one chapter;
Few editors who had thought to add the content tags were correctly tagging the articles as LWS3; they were usually tagged as either HoT (accurate, but unspecific) or Flashpoint (not accounted for by the template).

I've already addressed half of the latter problem by tweaking {{Living World Season 3 content}}, {{Living World Season 2 content}}, and {{Infobox release}} so there's an option to autocategorize by release chapter. Going forward, I want to organize the categories:

Proposed structure

Category:Living World Season 2 content
- Category:Living World Season 2 storyline
  - Category:<LWS2 chapter name> storyline
    - Story mission articles
  - Category:<LWS2 chapter name> content
    - Miscellaneous articles
Category:Heart of Thorns content
- Miscellaneous articles
- Category:Heart of Thorns storyline
  - Story mission articles
- Category:Living World Season 3 content
  - Category:Living World Season 3 storyline
    - Category:<LWS3 chapter name> storyline
      - Story mission articles
    - Category:<LWS3 chapter name> content
      - Miscellaneous articles

Current structure for comparison

Category:Living World Season 2 content
- Miscellaneous articles
- Category:<LWS2 chapter name>
  - Story mission and miscellaneous articles
Category:Heart of Thorns content
- Miscellaneous articles
- Category:Heart of Thorns storyline
  - Story mission articles
- Category:Living World Season 3 content
  - Miscellaneous articles
  - Category:<LWS3 chapter name>
    - Story mission and miscellaneous articles

Changing the structure should be fairly straightforward, though {{Personal story infobox}} is tripping me up. It seems to autocategorize independently of {{Infobox release}} and I haven't figured out how as of yet. I'll also need to edit {{Living World Season 3 content}}, {{Living World Season 2 content}}, and {{Infobox release}}, but I already know what I need to do for those.

And as if this comment of mine wasn't long enough already: once the categories and templates are finalized, I plan on using a bot to tag pertinent articles correctly, but I'm having trouble seeing how a bot will be able to easily find pages that need categorizing, since release-content spans a wide variety of objects, maps, npcs, etc etc... I'm thinking I'll just find all the articles manually and post them to my sandbox in a nice easy-to-use list for the bot to comb through. --Idris (talk) 01:12, 19 June 2017 (UTC)

It is my belief that the only things that need to be in release categories are: story instances, achievement guides/lists, and overarching location articles (instances or zones). NPCs and the like do not need to be in them.

I'm rather doubtful that things like 13 Zephyr, 1329 AE even need to exist, truth be told, since they're just an achievement entry and the object linked in those particular cases are "Torn Page" or something like that.

Individual items like Druid Runestone or M.O.X. similarly I doubt need to be in a category declaring it having been released with a certain episode/season/boxed storyline. They should denote on the article they're part of that storyline, yes, but categorized in such? Unneeded, IMHO.

Given the three above facts, I think we need just two "layers" of categories. One for the overarching storyline (core, Season 1, Season 2, HoT, Season 3, etc), and one for the individual releases (Out of the Shadows, Flashpoint, etc.), the former only containing overarching articles like Living World Season 1, the latter containing aforementioned story instances, achievement guides/lists, and zones/instances (and similar overarching-of-that-episode articles). Konig (talk) 02:42, 19 June 2017 (UTC)

Also looking through Category:Living World Season 3 content, I'm seeing a lot tagged for it that I wouldn't think should be - such as Foefire Wraps. It was released alongside Season 3, but Season 3 is not needed to obtain these things so I don't feel it should be listed as Season 3. In either category or article. Konig (talk) 03:25, 19 June 2017 (UTC)

I see what you mean with regard to item/NPC/etc articles. I reckon I agree. The trouble is, a lot of editors are prone to helpfully adding the release tag to articles like these, as well as arguably-unrelated articles such as the Foefire Wraps that you mentioned. We'd need a way to prevent these helpful attempts from bloating the categories. The best solution I can come up with is to alter the content templates so they no longer autocategorize, and add a new parameter to location/achievement infoboxes so they begin autocategorizing. --Idris (talk) 19:19, 19 June 2017 (UTC)

We should be able to remove the autocategorization from the release template that the infoboxes pull and attach it straight to the infoboxes we want to autocategorize (area and story infoboxes imo). NPCs and items released as part of the season should continue to be tagged as we've begun doing but not those added during the time span of the releases but independent from (like the new wvw rewards which are tagged as season 3 despite zero relation besides release date). 01:17, 20 June 2017 (UTC)

I agree with {{Location infobox}} and {{story infobox}}, and I'd also like to add something for achievements. That will be tricky though, as both {{achievement box}} and {{achievement list}} get transcluded on other articles, including items, NPCs, etc. My thought is to simply remove all uses of {{achievement list}} from any articles that aren't intended to be pure achievement lists and replace it with {{achievement box}}, then add the autocategorization to the former. --Idris (talk) 01:44, 20 June 2017 (UTC)

...And I've just noticed that we have three story-related infoboxes: {{story infobox}}, {{personal story infobox}}, and {{living world infobox}}. I'm not sure what the reasoning for this is. --Idris (talk) 01:49, 20 June 2017 (UTC)

(Reset indent) I haven't forgotten about this. Between content patches keeping everyone busy and my internet dying for a month, I haven't been able to tackle it. I'd like to get it sorted before the new expansion hits, though, so I'll probably start soon. If anyone has comments they'd like to make before I start overhauling, please speak up. --Idris (talk) 16:55, 30 July 2017 (UTC)

Okay let's have a look:

I shall merge the story infoboxes in all cases and make them categorize without being hardcoded, then we can figure out a better way forwards.
Category:Heart of Thorns content is applied to any page using the little icon in the top right, set by {{Heart of Thorns content}} or {{infobox status}}. I think we should ignore this category.

This is a mess. -Chieftain Alex

17:54, 30 July 2017 (UTC)

Thanks for tackling the infoboxes. I'm not sure I understand what you're saying with your second point, though. And I agree, this is a mess. --Idris (talk) 18:53, 30 July 2017 (UTC)

I'm suggesting it's too broad a category to expect to find anything useful in. I'm thinking about removing the categories from the nav templates such that the infobox does everything (they all use {{story infobox}} now). -Chieftain Alex

21:48, 30 July 2017 (UTC)

I ended up creating Category:Story Journal, and making the story infobox do all the work with regards to categorizing it into the subcategories. -Chieftain Alex

17:15, 24 August 2017 (UTC)

Event Categories

I was going through the event categories trying to make the Category:Events page a little more complete with having the zone event categories contain their respective area event categories, but when I looked on the main events categories page, I noticed a large inconsistency. Many events were categorized to the parent zone, completely bypassing the area category completely. I dug around a bit in the community portal archives and couldn't find anything regarding any such policy on how events should be categorized. So, I felt that perhaps there should be some discussion on which method of categorizing the events should be used, rather than going rogue and further spamming the recent changes with dozens of changes and new pages as I see personally fit. -Yossitaru (talk) 05:31, 20 June 2017 (UTC)

In my opinion, events should go in their zone categories (not areas). I am aware of some buggy behaviour related to the category autodetection which is breaking their categories. I don't think there is any benefit to splitting the events further than by zone, you're going to end up with lots of small awkward-to-use categories with no content. -Chieftain Alex

06:13, 20 June 2017 (UTC)

Not sure what caused stuff to break but I had my bot clear and restore the zone pages so all of the false event categories should be fixing themselves now and should be all gone shortly. I'm also of the same mindset as Alex, espeically when sometimes events are in the wrong spot, and upon correcting it, suddenly you have an empty category. - Do_odleplex 07:39, 20 June 2017 (UTC)

Well, my fault for taking such a weird bug as something that needed a more severe fixing. It's just rather odd it only affected some and not all. And the fact that the Mists, that one category for Tutorial events, and one zone for Ascalonian Catacombs are set up in a hierarchical fashion certainly didn't aid my judgement. -Yossitaru (talk) 09:27, 20 June 2017 (UTC)

Warband Worms

So going through the orphan pages, I've noticed a lot of orphan warbands. At first, I would just attempt to connect the dots by adding in a sentence here and there. Then I happened to actually check the Talk:Warband page. There seemed to be a general consensus (2 years ago) that the minor warband pages shouldn't need to exist anymore, since the absolutely stupendous chart was included in the main page. So before I go haywire and start putting in deletion requests, is all this kosher? --Rain Spell (talk)

I'd say if it has 3 member or less mark it for deletion, as to me that's what I'd call small/minor. - Do_odleplex 09:04, 11 July 2017 (UTC)

Sounds good! I've been itching to get them off that list.--Rain Spell (talk)

Ascended Breathers

I'm looking at the following pages:

[[Maklain's Metal Breather]] / [[Maklain's Leather Breather]] / [[Maklain's Cloth Breather]]
[[Ossa's Metal Breather]] / [[Ossa's Leather Breather]] / [[Ossa's Cloth Breather]]
[[Ruka's Metal Breather]] / [[Ruka's Leather Breather]] / [[Ruka's Cloth Breather]]
[[Svaard's Metal Breather]] / [[Svaard's Leather Breather]] / [[Svaard's Cloth Breather]]
[[Tizlak's Metal Breather]] / [[Tizlak's Leather Breather]] / [[Tizlak's Cloth Breather]]
[[Yassith's Metal Breather]] / [[Yassith's Leather Breather]] / [[Yassith's Cloth Breather]]

Darqam put these pages together when ascended breathers were just released - he didn't know for sure that they existed; he just expected that they did exist (or at least would exist sometime "soon"). Given how long it's been and how they introduced Wegloop breathers I don't think that these generic breathers will ever be released. Should we delete them all?

I can understand that they may be someday added, but if that happens then we can recreate the pages then. Un-burn that bridge when we come to it, if you will. --Imry (talk) 05:57, 11 July 2017 (UTC)

I don't think "future" is appropriate anymore, I'd suggest changing status = future to status = unimplemented. We know these items "exist" (they have IDs) we just can't obtain them. -Chieftain Alex

06:29, 11 July 2017 (UTC)

Agreed, just leave them be, but marked properly. They have unimplemented value! —Ventriloquist 10:39, 11 July 2017 (UTC)

My only concern with unimplemented is that (in my opinion) that tag is usually meant for content that we have at least had hints about (data mine or otherwise). In this case the pages were purely made because I expected those armor pieces to exist because of logic (lol), and no actual evidence they ever would appear. Because of that I'd be alright with either deleting them, or doing what Konig suggested on my talk page "I'd suggest redirecting generic-named non-existent ascended aquabreathers to a page akin to Ascended armor (there doesn't seem to be an article detailing the available aquabreathers yet, so such should go either on Ascended armor or Ascended trinket), for those who would search for them, and have the article note that not all prefixes can be crafted but are available from Bitterfrost Frontier.".

That said, I've got nothing against it just being unimplemented content but I want to be clear that the original creation of those pages had no solid grounds whatsoever. -Darqam 14:24, 11 July 2017 (UTC)

(copy paste from talk page: I think it's ok to keep them for awhile longer yet. Anet took 4 years to come out with ascended aquabreathers, and people looking for an aqua-breather with that stat set will at least see that it hasn't been implemented into the game yet. (Instead of thinking they just can't find the right page)). I'm all for linking (or creating an ascended/aquabreather) them to the ascended page and just making a note that these were unimplemented. Even though they weren't officially "planned", they're a reasonable extension for people to expect. --Rain Spell (talk)

Oh wait, I got confused when I saw the skin id. So no item ids and pure guesswork? Hmm in that case these pages are misleading. (Sorry for the incorrect info)

Would it be more useful to redirect each of these non-existant items to a section on Breathing apparatus (e.g. #Heart of Thorn stats), or just plain up delete them? -Chieftain Alex

17:16, 11 July 2017 (UTC)

Also, apparently the recipe template causes them to appear falsely on pages like Damask Breather Strap#Used in - I'd also delete/redirect the recipe sheet pages too. -Chieftain Alex

17:18, 11 July 2017 (UTC)

Ooh, yeah, we're gonna have to delete the recipe pages too.

Yep, they're pure guesswork. Turning them into redirects would work - I had an idea of putting a note at the bottom the armour set pages (like Maklain's armor) saying that there's no craftable aquabreathers in this set, but putting it on the breathing apparatus page looks much simpler. --Imry (talk) 06:38, 12 July 2017 (UTC)

Hints on collection items

The recent Legendary Trinket collection has us collecting many different items. They have hints indicated in the achievement panel. However, the items themselves do not have a hint. How should we approach this? There are a few ways I can think of right now:

Create two different articles, one for the achievement panel and one for the actual item.
To simply add the hint onto the item page.
Remove all hints from existing item articles and only have the hints listed on the achievement article.

Personally, I don't care which one it is. But as a result of this confusion, some articles I've created are inconsistent with others'. Sythe 06:18, 27 July 2017 (UTC)

I'm going to get flak for this, but add the hint to the item article using the "hint" parameter in the item infobox, and hardcode it onto the achievement page in a table too. (a bit like Kraitkin III: Venom + items). -Chieftain Alex

06:38, 27 July 2017 (UTC)

On skill/trait icons and the leaks

→ moved from Talk:Main Page

Ok so currently with all the news and excitement going around it's very difficult to see what has been revealed and what came from the leaks from a few months ago (which where completely and utterly correct), thou one thing we can know for almost certain comes from the leaks are high coality skill/trait icons, so what is going to be our stance on this? Do we allow this and go for quality or do we take a strong no leak stance and go for integrity? (same kinda applies to the new mastery lines) --Doctor Refrence (talk) 12:01, 2 August 2017 (UTC)

I think most of the information is actually coming from WoodenPotatoes's stream. He was given early access to the expansion and was officially supported by ANet in streaming footage of it, so it's perfectly safe to copy anything from his video. I don't think it's really necessary to use any of the leaked images, even if they're of a higher quality, because perfect-quality icons will be available as soon as the expansion goes live (perhaps even earlier). Check out Darqam's dat icons project -- he rips them straight from the gw2.dat file. Also, when you have other questions/suggestions like this in future, I recommend posting them to the community portal instead -- this page is really more for comments about the wiki's main page itself. :) --Idris (talk) 12:28, 2 August 2017 (UTC)

(Edit conflict) Couldn't we see the icons from the streams? Or are you referring to some specific ones that weren't on the streams? Inculpatus cedo (talk) 12:41, 2 August 2017 (UTC)

We could see a few of them, but most of those are of a lower quality than the ones from the leaks, and the same leaks also contain both info and images for the masteries of the new mounts. Link for the uninitiated (spoilers, duh) --Doctor Refrence (talk) 12:56, 2 August 2017 (UTC)

Inculpatus, be careful when there's an edit conflict, you accidentally deleted my comment. :p --Idris (talk) 13:06, 2 August 2017 (UTC)

A few of things: 1) We're not in the habit of posting "leaks" on the wiki. 2) Our current method of gathering icons from the .dat is already a contentious issue. 3) the Skills API will give us access to the icons soon enough.

I'm glad we're all so very excited to get information about the expansion up on the wiki, and also stay ahead of the game to make things easier on us. I'm of the mind that in this particular instance, we don't need to be so quick out of the gate (i.e. out before the starter gun). G R E E N E R 15:59, 2 August 2017 (UTC)

I didn't realise we could access the icons through the API. ~~How is that done?~~ Edit: Nevermind, it explains in the documentation. Thanks for the heads up! --Idris (talk) 16:03, 2 August 2017 (UTC)

I'd somewhat argue that getting simple things out of the way now (like icons) wouldn't be a bad idea before being swamped with the expac release. If not uploaded, at least have them ready. -Towelcat (talk) 13:42, 12 August 2017 (UTC)

I missed this comment yesterday, but I've done all the skill/trait icons at [[User:AWB Alex/icon uploads]] (sorted by profession and type). If we know their names + which icon, then I've uploaded them already afaik. -Chieftain Alex

22:03, 13 August 2017 (UTC)

Lesser skills

Would it be a good idea to categorise the lesser skills in a Lesser Skill category? I think that adding this category would make it a little bit more manageable for readers to both understand what lesser means and to see how many there are ingame at the moment. --Doctor Refrence (talk) 12:28, 12 August 2017 (UTC)

An other discussion point I want to bring up (and why I renamed this discussion to just Lesser Skills): How should we format the Lesser Skill infoboxes. I think User:Cricket's (example: Lesser Muddy Terrain) way of formatting these skills, with the Trait as an Parent skill and the Normal skill in the "See also" section, allows us to make the relation between Trait and Skill more clear than our current system (example: Lesser Spinal Shivers). Because of this I would also like to suggest that the parameter | parent = in Template:Skill infobox gets split up into parameter | parent skill = and | parent trait = . Let me hear what you everyone else thinks! --Doctor Refrence (talk) 19:47, 13 August 2017 (UTC)

Feel free to create "Category:Lesser skills" and manually add the category to those pages if you want to. It'd be a sub-category of Category:Skills or maybe Category:Skill types
I think slot = trait should be in there - it's not otherwise obvious that it's a trait skill whilst using SMW data.
How would you feel if we still use slot and trait parameters, but it ends up with an icon for the trait, and hence the same appearance as in Cricket's Lesser Muddy Terrain, whilst using the wikicode from Lesser Spinal Shivers?
Also I don't think we should link to the "list of <prof> skills" if it's a trait skill page. I'll change the behaviour.

-Chieftain Alex

22:03, 13 August 2017 (UTC)

I think that if we can get the icons working for that Parameter it would be perfect imo. And alright I will go ahead and make the category as part of the Category:Skills. --Doctor Refrence (talk) 07:26, 14 August 2017 (UTC)

Alright I've added the icon. Thanks for your feedback. -Chieftain Alex

20:08, 15 August 2017 (UTC)

A Great, thanks! I have categorized and uniformed all lesser skills to use a similair lay out (including the use of the updated trait parameter). Only thing I can't currently test is if the chat codes are still correct.--Doctor Refrence (talk) 22:09, 15 August 2017 (UTC)

General formatting guides

With a new expansion on the horizon, we're facing a huge amount of new content that will require new articles to be created, and likely an influx of new users to help out. I think now would be the perfect time to review the Guild Wars 2 Wiki:General formatting guides, as many of them are out-of-date and some (traits, effects, etc) are missing. I've already made a start on updating them, but I thought I'd leave a heads-up here if anyone wants to help me. --Idris (talk) 14:51, 2 August 2017 (UTC)

Thanks for looking into these. As a general statement, there's a difference between scaffolding (giving editors a framework to build off of) and dictating (saying, "This is how we do things around here!"). I hope the messaging from the guides is more on the former than the latter.

Also, as Vent and others are aware, I'm terrible at such conforming, so as much as I wish I could, I don't think this is where I can help too much. I am sure that others will come along and lend a hand, though. G R E E N E R 16:12, 2 August 2017 (UTC)

Ditto, every time I edit an npc article it needs bleaching. -Chieftain Alex

17:29, 2 August 2017 (UTC)

I wouldn't mind helping make an Effect formatting page. Anet releases like 20 new effects every living story update, and while they're all very uniform at the moment, I think that's because it's the same few people working on them, not because it's easy to find the formatting. (When I started, I spent like 2 hours figuring out how the effect infoboxes worked, etc.) And I think consistency in linking effects for Achievements and Skills is important.--Rain Spell (talk) 21:19, 2 August 2017 (UTC)

I've expanded the list of guides on the general formatting page; some of them are red links (including effects), so go nuts. :) --Idris (talk) 18:30, 3 August 2017 (UTC)

I love the table! Not sure about two things though: Raids are formatted the same as dungeons, so I'd probably remove that link and tweak above text accordingly. Also I think Mastery Insights could easily go on the Object page, but I don't mind either way there. - Do_odleplex 18:36, 3 August 2017 (UTC)

Ah, wasn't sure about raids. Will fix. I was tempted to include mastery insights on the objects page too, but then I noticed that hero challenges have their own page, and realised that it's not immediately obvious that hero challenges and insights are "objects", so I think it's helpful to list them separately. Do you think they should share an article though? --Idris (talk) 18:40, 3 August 2017 (UTC)

Hero challenges come in many different types so that's why they have their own pages, but since Mastery Insights are virtually the same as communing hero challenges that could fit nicely there. Perhaps a slight tweak of adding "getting there" since some mastery insights are like mini jumping puzzles should be added if that happens, which if nobody has any other objections or inputs, I'd say go ahead and do. - Do_odleplex 18:48, 3 August 2017 (UTC)

Done. --Idris (talk) 19:20, 3 August 2017 (UTC)

Oh, and Greener: since diplomacy is your strong suit, I think you'd actually be a great asset to this project, as you can help ensure the wording is appropriate. I'm sure I've already messed up and come across as dictatorial in a few places already. --Idris (talk) 18:46, 3 August 2017 (UTC)

Sure, so a few things I'd like to point out, and encourage feedback on.

First, we want to make sure our messaging is on point. Every well-intentioned edit is appreciated, and no one should feel like they cannot contribute because they can't live up to our standards. If we present ourselves as having formats and rules, we'll ostracize parts of our community.
Second, I hope we're not setting ourselves up for what I consider to be bad habits. I don't want to see wiki editors going around and changing the order of sections because "that's how we do things". For example, if the "Content" header is above the "Acquisition" header, does it really matter? We should be making sure the information order on that page is conducive to the reader, rather than conforming to a predetermined format.

To these ends, I'll offer a few suggestions, all of which likely need massaging from you folks. Rather than naming the pages "Event formatting", which by its nature creates and reinforces a constrained view of what's allowable, let's allow ourselves to be more open. May I suggest naming the pages, "Guide to event pages", etc.? I'm also curious on if we can reduce the splash of information that players get when looking at pages such as Guild Wars 2 Wiki:Event formatting. It's a tad overwhelming, and I wonder what it would be like if we put the copy/paste version first.

I love how we're giving contributors, new and old, helpful tools. Let's make sure we're not sending them handcuffs at the same time ; ). G R E E N E R 23:13, 3 August 2017 (UTC)

Thanks for the suggestions. I'm not opposed to renaming the formatting articles, but I'm not keen on doing it myself because I don't have a bot that can deal with all the broken links left in its wake. (I dislike linking to redirects.) As for the splash of information coming before the template -- personally, I prefer showing guide information first; the templates tend to be quite large, so I worry that users seeking the information will miss it if it's hidden at the bottom. Rewording the first sentence to something like "skip straight to the template if you want" and forcing the ToC to display so they can get to it quickly might be a better solution. --Idris (talk) 12:41, 4 August 2017 (UTC)

Any chance of getting a PvP loot box guide/framework? I usually clean up as I might otherwise edit, but I'm sure that there are things that I keep as they are due to others in the same Reward track. (i.e. the acquisition section: Tier 1, 1st reward. (1st of total.) vs without (). Also order of drops, and to sub-section or not sub-section.) Adeira Tasharo (talk) 00:05, 21 August 2017 (UTC)

Wiki header file / theme for Path of Fire

Hi guys. We need some artists, so get your painting hats on and easels out. If you've got arty gw2 friends, rope them in. We could do with the following:

Skin header (i.e. the colour bit in the top left behind the logo + tabs)

Currently we're using File:Skin header purple mist.png as a stop-gap until something decent is agreed on.
The original files are red + green, but we're looking for something closer to the purples and magentas of the new expansion.
We've had some preliminary playing around in User:Chieftain Alex/sandbox6 (+talk)

Main Page/editcopy

It'd be nice to have some new matching files left and right. The current files are here and here.
New release content suggestions.
{{Main Page/featured}} - this could be prepared for the release.

Stephane has provided a few textures to get us started:Talk:Main Page#New background needed?. -Chieftain Alex 21:03, 8 August 2017 (UTC)

New launcher! We could steal the art from it to make our background, perhaps? --Idris (talk) 21:17, 8 August 2017 (UTC)

File:PoF_Launcher_art_clean.png <-- Uploaded it for easier use. --Idris (talk) 21:33, 8 August 2017 (UTC)

I've applied your changes to the Main Page, it looks great. I'm not going to win any friends with my edits over the last 10 minutes, but I have also applied a header file I did that was a slightly better colour match than the previous one. When there's some agreement I'll change it over again. Also, sorry for protecting the images which will seem like I'm preventing their being edited - which is true in a way, I just don't want spambots replacing them :< -Chieftain Alex

21:16, 11 August 2017 (UTC)

The banner you chose is a good placeholder! I like the way the orange shines in from the right like the sun. If we applied that colour to Inc's #2, I daresay we're onto a winner. --Idris (talk) 00:59, 12 August 2017 (UTC)

I reckon we've been using that "placeholder" for long enough that it's become our official banner at this point. But man, the French really knocked theirs out of the park. --Idris (talk) 07:47, 14 October 2017 (UTC)

A few more pictures

I've added a few more pictures that could be useful to the GW2 wikis, including additional concept arts:

Let me know if the wiki has other, specific needs! Thanks everyone for your awesome work :) --Stephane Lo Presti talk 23:21, 10 August 2017 (UTC)

list of unmatched searches (chatcodes)

is there a way to display all recent chatcode searches which did not match a page? this would make adding items a lot easier when pof hits, as those who edit the wiki wouldn't have to get the item themselves. I've added a few of the Sunspear weapons during the beta weekend and the only way I could do that was to farm unidentified gear and get them myself. being able to see all searched chatlinks would really speed up the process and convincing players, who are not prepared to edit the wiki themselves, to at least /wiki link their items (and effects and stuff) should be manageable enough (i.e. by posting on reddit a few days prior to launch). even better would be if all unknown id's would get added to a page and automatically removed once the id has been added to an item. Oranisagu (talk) 13:58, 16 August 2017 (UTC)

Maybe. The ids are stored in the API, so in theory we could write a script that takes each id and then trawls through the wiki in search of a match. Sounds like it would take forever to load, though. --Idris (talk) 17:23, 16 August 2017 (UTC)

I've played around with the #ask command in the hopes I could generate a list of all items in the wiki (like the vendor list and stuff like that) but I couldn't get it to work, as I don't really understand the system. if it was possible to generate a list of all ids in the wiki and then compare it to the list /v2/items spits out, it could be a way to find all missing items, add them or create an exclusion list for those not interesting enough to add. I mean this wouldn't have to be something that's done often, just every so often (as I think the API won't give item ids of things that haven't been found by players yet) Oranisagu (talk) 17:45, 16 August 2017 (UTC)

Sadly each chatcode query is generated on-the-fly on the client end using Javascript, the wiki never logs any results of what is searched for, therefore we can't add a list of automated items-searched-for-without-results.

We could however maintain a list of item ids within the API, and monitor the newly added ids (fairly trivial to do), and then query the wiki for the newly added ids. We would have to manually choose when to update the diff though.

There's a catch to using #ask with more than 5000 results- it's limited to an offset of 5000 +/- 500. Since we've got 51232 item ids denoted on the wiki, we can only really query for the first 5000 of them, which sucks for comparison. The good news is the items API has 57262 items, so we're not really missing too many (11%). I'll figure out a way to pull out the remaining ids. -Chieftain Alex

21:19, 16 August 2017 (UTC)

Here is a list of missing item ids from the wiki. raw / table-Chieftain Alex

22:37, 16 August 2017 (UTC)

A lot of these probably aren't directly viewable in-game or no longer exist because they are kept exactly the same but assigned a new id. I think we only care about items that are missing ids and don't already have an item article with the item name.--Relyk ~ talk < 04:53, 17 August 2017 (UTC)

Doesn't User:Darqam/GW2W Easy Mode#View New Entries effectively perform the same function? --Imry (talk) 05:57, 17 August 2017 (UTC)

I feel like a skritt in Tarir right now. --Idris (talk) 06:20, 17 August 2017 (UTC)

Same, since I like to root around in the item db. I'm seeing a lot of items in that list that were retired when they removed Magic Find from gear. SarielV

15:27, 25 August 2017 (UTC)

Nav box rework, version 2017

So, here we go again, I'd like to propose yet another revamp of several nav boxes.

A couple days ago I stumbled upon this navbox on the French wiki, and I realized that we don't have any option in the profession navbox to navigate from a profession to its elite specs, and also, for some reason, that ever since we removed elite spec skills from the core profession skill lists, no navbox we have manages to navigate between all pages with (at least non-racial) skill lists either. And since I had a few issues with a couple of our navboxes anyway, as well as with the situation changing a bit now that we have 2 elite specs per profession, I decided to try and improve our navigation between related pages once again. For this purpose I took the idea behind {{Specializations nav}} of showing a single profession by default and having the rest expandable, which I find to be a nice solution to the problem of the ever-growing amount of links to navigate between, and applied it elsewhere as well. At first, my plan was to try and make the navboxes adapt a bit more to the type of page it's on (such as a bit different default view on Elementalist vs. List of elementalist skills), but in the end I found it a bit unwieldy and unintuitive. So, right now, this is my suggestion:

User:Noxx/Navs

Professions, specializations, lists of skills and traits
The current profession nav has bothered me with its square dimensions and surprisingly big focus on the Specialization page compared to the professions themselves ever since its last rework. I propose to add elite specs to it, since I think that might be a common use-case, and, similarly to the spec nav, to focus on a single profession by default while having the others expandable. Since it would replace the profession nav, it would still be useful to have a simple, concise list of all professions visible even before the expansion. A small problem would be elite spec pages, which would either end up having 2 navboxes under each other (Profession and Specialization) or one of them would be missing, breaking the intuitiveness of bi-directional navigation. A solution to this might be to merge the 2 similar navboxes into one – navigation from, say, Elementalist to Fire might not be that useful (hence making the core specs smaller in size), but the other way round would be.

Races and racial skills
I always wanted to have profession and racial skills link to each other, but I realized once again that is simply unfeasible. However, we should at least merge these two navs together.

Skill types and profession mechanics
These two nav boxes are quite weird: they have a significant overlap and they're rather messy. When we only had one elite spec per profession, marking elite spec skills and mechanics with italics made some sense, but now it's useless. Because it's often difficult to tell whether something is a skill or a mechanic (as it might be both), I suggest merging these two navs and using the italics for the mechanics instead. My main suggestion would be to follow a similar format to the spec and now profession navs in having only the relevant professions opened by default, and having a row for each elite spec so that they're distinguishable from each other. The disadvantage to this is that as time goes on, the table will get quite long, especially for something like Signet. I was thinking about multiple solutions, if need be – reworking the nav from divs to an expandable table, or hiding all professions for shared types by default – but I don't like either one. An alternative suggestion is to throw everything together, with varying degrees of icon usage and grouping, but they end up much harder to navigate, especially if you throw in every specific single-skill mechanic (like Steal) to the list, whcih the first suggestion handles much better.

Obviously, if I didn't think these would be an improvement, I wouldn't even suggest them; my personal pick would be versions (1eb), (2b), and (3aa) or (3ad). Now I turn to you: do you have any comments or ideas? Would you approve or oppose these changes? 20:29, 19 August 2017 (UTC)

I'm a fan of (1eb) for what it's including, though there's an argument for keeping specialization in the row in (1ea). The rest I'm neutral on, or I'll have to take more time to ponder, though please, not (2c)! Thanks for diving into this for us. G R E E N E R 21:42, 19 August 2017 (UTC)

Because there's no real point to having navs like this only static, I turned the more promising nav boxes to proper dynamic templates with a couple more examples:

(1eb) Professions + Specializations – turning it to (1ea) would be trivial
(3aa) Skill types + Profession mechanics (detailed)
(3ad) Skill types + Profession mechanics (concise)

Don't worry, (2c) is out of the question, that was a dead end. So, any more feedback? Preferences? Reasons why you might prefer the current navs? Knowledge of less hacky way to turn collapsing into toggles?

19:43, 22 August 2017 (UTC)

*crickets* ... Given the relatively speaking overwhelming support, I'll probably try to implement these in a couple days, unless someone suddenly comes and convinces me not to. I'm currently leaning to versions (1eb), (2b), and (3ad) – for future proofing reasons.

22:47, 25 August 2017 (UTC)

Sorry to not have cycled back as I said I would. For the Professions + Specializations, could we equalize the font sizes? I know you're avoiding the long text for rangers, but the changing of the font size keeps trying to tell me to ignore some things and look at others, when all are equally important.

I love the future-proofing on Skill types + Profession mechanics. I'm curious about the use-cases. If we put these on Trap, will we be using "Trap" as a parameter and only showing the professions which use traps? While that's great for the skills listed above, wouldn't a person want full access to all of the skill types in the nav at the bottom? Just wondering about the perspective on that point. Otherwise, I do like how the profession's set of skills can be highlighted on the "detailed" version (my preferred version for the use-cases that I can think of atm). G R E E N E R 23:02, 25 August 2017 (UTC)

The feeling of the core specialization links being less important was intended, as everything on those pages is already covered by the Traits link in the previous row, so those links are there more to navigate from those pages rather than to them. But if you'd prefer to have them all equal like this, I have no problem with changing that.

The (3ad) skill types + mechanics shows professions (and if necessary elite specializations) which have that skill type by default, and then there's the toggle All links to show everything at once. Is that toggle easy to miss? How would you try to improve that? Would simply expanding the text to something like All professions, specializations and parameters or All types and mechanics be enough?

The reason for hiding things by default is that there's a lot of links to cover, and the list only gets longer with each new expansion as new skill types and elite specs come into the game. I'm ever so slightly worried about (3ad) that it's not obvious enough the elite spec types are shown by default if and only if that very spec has that type, and other elite specs are hidden at first. I was also considering changing the profession name to that of the elite spec if that one is shown (so that the default view of Trap would show lines for Dragonhunter, Ranger, Thief), but I think that would make it difficult to tell elites apart from core professions, and it doesn't future-proof for the case that multiple elites might theoretically share a new skill type.

In that sense I prefer the (3aa) version, but the default Signet view (as shown in the template links) in that is already way too long, and it will only get longer as new elite specs are released, so I tried to look for an alternative. I'm open to suggestions, though.

07:24, 26 August 2017 (UTC)

I did glaze over the toggle, and I've redacted my statement above. I'm thinking this is a case of old-dog/new-tricks when it comes to how our navs have worked in the past. I do appreciate the toggle to see more when I notice it.

As for font size, I find the equalized fonts to be far easier to look at, both holistically and when I'm looking for details. Even shrinking down the elite specialization icons just a bit might help it not be so chunky. Yes, at this point I'm nit-picking on a nav that I think would work well. I'm all for your Professions Nav.

And now, combining the two points above (toggles are good; small fonts are bad), I think if you increase the font size for "All links [show]" on your Concise Skill Types Nav then you'll have a winner with the in my mind. Thanks for pointing out future-proofing with the signets; it does show the way that Anet's trending which we need to prepare for. G R E E N E R 17:44, 26 August 2017 (UTC)

I wouldn't want to shrink the specialization icons – they are made with these sizes in mind (the small versions are often simplified) and scaling them would make them blurry and with overall lesser quality. But I did increase the problematic font sizes, is it better now? ^^

19:56, 26 August 2017 (UTC)

Love them. Now that the fonts are equalized, the icons don't seem as big. If no one has objections in the next few days, I'd say run with them. And again, seriously thank you for readdressing these navs! It's a complex issue which you've grabbed a great hold of. G R E E N E R 20:09, 26 August 2017 (UTC)

I've only really looked at the professions one (jesus christ the source wikicode on the skill types one...) - their appearance is fine, other than I wouldn't set the "any" background colour within navs, it looks nasty when you collapse/expand it. -Chieftain Alex

15:26, 27 August 2017 (UTC)

I'm not sure how much of a performance killer the plethora of variable definitions is, I simply took the {{Specializations nav}} source code and expanded upon it, and given the programming rule to avoid premature optimizations it seemed okay to me. And when it comes to the link definitions, well, I agree, it's terrible. :D Originally I was simply listing the page names and using {{cname}} and Category:Profession mechanics to look up the rest, but there were quite a lot of inconsistencies compared to what I wanted it to look like that would require bigger changes to some pages I didn't want to do just for my suggestion, so I encoded it all into the page in order to focus on other things. For instance, I didn't manage to lookup Pet as a profession mechanic (but that was probably due to my minimal understanding of semantic queries), future mechanics aren't being categorized yet, Legendary Assassin and Photon Forge would probably need to be split into the skill and type/mechanic for separate names, and so on. Obviously, if you know of a better way to set all that up, feel free to show me, I'd love to learn. ^^

15:59, 27 August 2017 (UTC)

Oh it loads quick enough, it's just when the next guy comes along and pressed edit and doesn't find something that looks like this. :) -Chieftain Alex

16:41, 27 August 2017 (UTC)

So, since no one else protested in the last week, I implemented the new navs. They are quite dynamic, so if you find issues on some pages, do tell (so far I realized I forgot to show anything by default for the "Other grouping" links in skill types, I'll go fix that now). I also changed the header colour on {{Skill types nav}} to "mech2", as per Template:STDT. The {{Specializations nav}}, {{Racial skills nav}} and {{Profession mechanics nav}} templates have been redirected to the other three, if you'd like the redirects to be removed, that would probably be a job for a bot. ^^

17:12, 2 September 2017 (UTC)

Zone navs

While we're on the topic of nav reworks, Doodle and I had a discussion about the state of zone navs a couple of days ago, about whether or not it was appropriate to include achievements in them. Doodle hasn't followed up on it in a few days because she's busy irl, so I thought I'd mention it here in case anyone has any thoughts to add: Read the discussion here; Example of one of the current zone navs here. --Idris (talk) 02:42, 20 August 2017 (UTC)

As far as I'm concerned, I feel like if a separate page is deservedly created solely to document an achievement (such as No Mask Left Behind), then it also deserves a place in the nav box. Minor achievements don't tend to get their own pages anyway, reducing the feared bloating of the table, and many pages are more about some sort of event, NPC or object, with the achievement just coming along for the ride – those achievements might just be covered by the More link. I agree the selection can get quite arbitrary at times, but I think that removing everything for that reason is an overreaction. I also wouldn't potentially be opposed to singling out JP achievements into their own Jumping puzzles row, even something like Mastery Insights gets one, but that's just a random thought...

Then again, I don't remember ever using the nav to switch between achievement pages, so if they get removed, I won't be starting riots about it either. ^^

18:21, 21 August 2017 (UTC)

I've been pondering. What about if the achievements that are linked were just the ones that had a mastery point awarded when completed? Those are usually the ones with the guides and also usually the ones people care about the most. Plus that would also make it less opinionated as to which ones should up in the nav, as well as makes both the HoT maps and LWS3 maps nav's be similar/more consistant. Also I'd rather switch the text from "more" or "see more" to something else, for some reason it doesn't sit well, though I can't put my finger on why. - Do_odleplex 17:52, 24 August 2017 (UTC)

There are some achievements which don't award mastery points but still require guides and thus, in my opinion, deserve to be included in the nav. I'm not in favour of this idea. --Idris (talk) 20:13, 24 August 2017 (UTC)

As previously mentioned on a user talk page, I like having the zone-specific collections on it. I thought that Storyteller: Balthazar + friends were great additions to the nav. -Chieftain Alex

20:23, 24 August 2017 (UTC)

My apologies for not being more clear. I meant other than the zone wide scavenger hunt and jumping puzzles, that the only other achievements in that nav are ones that award mastery points so it's consistent and things shouldn't get too bulky(or so I hope). - Do_odleplex 20:33, 24 August 2017 (UTC)

Oh, sure. As for the "more" label, I'm not opposed to changing it, though I can't think of an improvement on "more..." --Idris (talk) 20:46, 24 August 2017 (UTC)

I think I just don't like the word "more" in navs. What about (Full list) or something like that? - Do_odleplex 20:50, 24 August 2017 (UTC)

"All achievements"? --Idris (talk) 20:53, 24 August 2017 (UTC)

Hmm...what about (Full achievement list)? I think that should be clear enough. - Do_odleplex 20:58, 24 August 2017 (UTC)

Sure. I'd prefer a label that's not overly lengthy, but clear communication is more important. --Idris (talk) 22:19, 24 August 2017 (UTC)

Achievement Hints Getting Pages

As per User talk:Greener#Data Keys and Aquitaine.1679 and Dash's comments on the on Wiki of Gold for the set for the Conspiracy of Dunces achievement. After a bit of a "oh no!" moment, I thought I had a bug and had lost the data keys for the Shattered Observatory fractal achievement, I did a bit of poking around and discovered that things like Data Key 3, 31 Zephyr, 1328 AE, and Parable of Lyssa, Page 2 aren't actual items in game, they are in fact achievement hints with icons. This isn't a new thing by the way, check out Lion's Arch Exterminator, all of the hints there are in fact pictures of Karka, and yeah if you poke the API you'll find 50 "Karka Hatchling (80)". I'm guessing in order to make some hints have icons in the achievement panel, they had to code them like items, but they're not actual items that can be picked up, and I don't think they should have pages-they're not items and it's misleading to pages that makes them seem as such. I will note that there are some of the Legendary weapons collections that do have an odd trophy or to that is similar, in that nothing enters the inventory, but those usually involve having a physical item in the players inventory and the player doing something with it as a result, so I wouldn't exactly count those as achievement hints as much as using an object to end the little lore quest. - Do_odleplex 21:25, 20 August 2017 (UTC)

The API lists them as items so I think they should be added as items with a note that says it is consumed immediately. J.Tesla (talk) 22:03, 20 August 2017 (UTC)

The trick is they're not actually consumed because they're not actually items-it's basically an achievement hint indicated via an icon with mouseover text rather than just text. - Do_odleplex 22:27, 20 August 2017 (UTC)

I can link to them in game chat like other items. They appear to be an evolution from the old collection items that only have use as part of a collection. Golden Priory Buckle as an example. Only now instead of receiving the item and having to delete it, it deletes itself to save time. Achievement hints have their own different entry in the API and are labels as “text” with recent examples from the rock collector achievement. On the surface they may appear the same but if we go against the API we will have issues when plundering the API for new data entries and whenever we document the outlier cases like the legendary collections. We should keep everything as consistent as we can with the API. J.Tesla (talk) 22:53, 20 August 2017 (UTC)

But they're not items, they're hints, and as a result nothing is collected because these achievements aren't collection achievements, they're scavenger hunt achievements just like the lost coins and badges. Additionally, for most of the lore scavenger hunt achievements, there has been a physical item that is obtained upon starting the achievement which is where all of the things found go, and usually uses

or

, which look nothing like the hint's icon and as a result that's why originally I thought the Conspiracy of Dunces pages were actual items as well as why I thought I had a bug for the data keys. They're not items, and that's misleading. Also with Anet, nothing is really ever consistent, so because of that just it's in the API doesn't mean it's an item. - Do_odleplex 23:52, 20 August 2017 (UTC)

What Tesla is saying is that they are mechanically classified as items. However, they do not show up in the inventory at any given time (due to auto-consume/delete). They have API ids just like any item does. This is not like the lost coins and badges, which do not have such items. This is why they have icons in the achievement panel and can at times be alongside items that are seen in the inventory. If they were as you said, the entry in the achievement panel would be akin to what we see for meta achievements - a list of short sentences, not a square icon-filled box with highlighting text. Konig (talk) 00:02, 21 August 2017 (UTC)

I understand what he's saying, I'm saying the ArenaNet is inconsistent and as a result things can be confusing and that tends to cause us hiccups and confusion. After pondering, I think the best thing to do is this: these pages get turned into redirects that go to the appropriate achievement page and the content be moved to the walkthrough on the achievement page with a note being put at the bottom that all of the items for the achievement never enter the inventory. That way the walkthroughs get the attention they need, nobody gets confused/mislead/wonders where the item went, and if people search for the hint/item/whatever they go to a page that gives them all the info they want on how to find it and the rest of the stuff for an achievement. - Do_odleplex 00:59, 21 August 2017 (UTC)

Uh, the game considers them items and therefore the wiki does. Creating an item page is preferred, just like with story journal items; we don't have to store an item subobject with the achievement object. The pattern should be the same as legendary weapon collections, where you are trashing all the useless achievement items right after getting them. I disagree with being confusing, as the achievement tracks all your items for you and navigating between the individual items and the achivement is not difficult or confusing. We should start adding the autoconsume flag to the infobox though.--Relyk ~ talk < 03:29, 21 August 2017 (UTC)

I've already discussed this at Greener's talk page, and can only agree with the several statements above. They're items, they have descriptions, IDs, icons and language links. They should be documented on this wiki. —Ventriloquist 10:41, 21 August 2017 (UTC)

We could add a new parameter to the item infobox that lets us specify if an item is a deleted-on-acquisition achievement hint? --Idris (talk) 15:42, 21 August 2017 (UTC)

I would think a line of text, rather than an infobox parameter, would be sufficient. E.g. "This item is autoconsumed upon receipt." -Chieftain Alex

17:03, 21 August 2017 (UTC)

I was thinking that the infobox approach would let us easily compile lists of such items, assuming we'd ever want to do that. --Idris (talk) 17:36, 21 August 2017 (UTC)

"Items which never entered my inventory and disappeared"... nah I think we'll cope without :D -Chieftain Alex

20:24, 24 August 2017 (UTC)

Ah, you know what ANet are like. They'll end up introducing a new mechanic that suddenly gives us a reason to need to SMW a bunch of previously ignorable mechanics. :p But fair enough. --Idris (talk) 22:20, 24 August 2017 (UTC)

We can do the "right thing" and add consumable types to the item infobox per the API and identify these as "Immediate" type.--Relyk ~ talk < 21:48, 26 August 2017 (UTC)

Not sure about non-consumable items, I would add an immediate parameter to the template for a flag, which is how we usually handle flags in infoboxes.--Relyk ~ talk < 22:28, 26 August 2017 (UTC)

The skill lists should describe the skill facts

Over time, the skill descriptions began to not really describe what a skill does - that's now described in the skill facts that accompany the description. This has made the wiki skill lists somewhat obsolete, in that, in order to really see what a skill does, reading the lists isn't enough - we have to click on the skills one by one.
For example, the Firebrand skills:

Core Cleave is described as "Cleave at your enemy with a physical and a magical axe". Nowhere in that description it mentions the skill applies bleeding.
Chapter 2: Igniting Burst is described as "Ignite the air around you in an expanding burst". No mention to how it causes weakness.

There are multiple other examples, including many of the Revenant and Mesmer skills.
I think the skill lists should be changed to include the skill facts. This would make them more comprehensive, and the total size of the lists wouldn't be bigger than the skill lists we had in the original Guild Wars (in which there were a lot more skills per profession). Erasculio 10:47, 28 August 2017 (UTC)

I agree with this a lot. In reality the descriptions often fill more of a role of flavour text, rather than truly describing what the skill does. I was thinking about whether we should show the skill facts in the lists even before the game launched, but at the time the descriptions were much more comprehensive so I didn't push for it. However, you're absolutely right that these days the lists are mostly a hub for links with the information people are actually looking for.

However, I'm still slightly afraid the resulting lists with the facts would get quite long and difficult to read. I tried making a very dirtily coded example at one of the longest lists we currently have (ele skills) to see what it would look like (it can take a while to load, I imagine the servers not being very happy about it :P). I don't know enough about semantic properties to know whether this would be feasible technically, but I hope so. I personally think the appearance is not that bad, and while it might take a while to get used to, it does make the list page much more useful. At the same time, I can imagine someone thinking it's a bit too long – I wonder, would it be possible to add a bit of local storage widget magic to add a checkbox at the top of the pages that would allow you to toggle the skill facts appearing, similarly to the settings in Event timers? Because if so, that should make both sides happy. ^^

17:20, 28 August 2017 (UTC)

Adding the facts adds about 13 seconds to the processing time (unacceptably slow imo). Part of this is probably that {{skill fact}} invokes {{effect}}, which then invokes {{effect icon}}, which then tries to lookup the SMW icon even if it isn't needed (we specified the icon in the top level template!) There's a few things we can start to do to make this workable. -Chieftain Alex

20:32, 28 August 2017 (UTC)

Bear in mind that the example I put together was looking up the skill facts with {{#dpl: | title = {{{1}}} | include = {Skill infobox}:variables }} inside of the row format template. Wouldn't an implementation with properties be faster? Or would that not be possible to do for whatever reason (a property couldn't hold that data, it would take too much space, it would be too slow anyway, or something like that)?

21:05, 28 August 2017 (UTC)

Since this is somewhat related, I want to add some properties for skills/traits, as seen here: User:Nefastu/Projects/Skills and traits. Maybe Applies condition/Applies boon would be interesting for the solution of this problem (if we don't want to include all skill facts)? —Nefastu 21:47, 28 August 2017 (UTC)

@Noxx, I'm thinking we just store the variables parameter as a text property, such that we can query for the output markup. Last time I proposed this it was argued that we couldn't ask for specific skills which apply bleeding etc, but bluntly that's a problem for another day.

DPL is slow only because template:skill facts is slow. Storing the output wikitext avoids the template speed issue I mentioned above. Also we're trying to slowly eliminate all dpl usage because it's no longer maintained as an extension. 217.42.240.161 22:39, 28 August 2017 (UTC)

(Reset indent) The {{skill fact}} template if for defining the skill fact subobjects on the the skill page. The template isn't meant for looking up and formatting a skill fact. Skill facts semantic properties (Guild Wars 2 Wiki:Semantic MediaWiki/Skill facts) aren't finished yet and haven't even started implementation, we were primarily waiting on the skill API. One of my goals with cleaning up skill facts to prep for skill fact subobjects.

We'll be creating subobjects no matter what. Here's the current strategy we have for lists:

What we will probably first do if semantic lookups are an issue is store the semantic lookups in the subobject. We did this for recipe tables and lists.
For lists, we can also store the initial look up for effect icons and canonical names in #variables so the page only pays for the initial lookup. I don't think we've done this yet with recipes as it's not needed, but would be the next step.
If we have a use case where that's too slow because we want to list 300 skills with skill facts, we have to store a wiki markup representation as a text property like Alex said. This requires way more maintenance and work and should be last resort.
13 second processing time for edits is acceptable for sparsely edited pages. For pages doing a large number of lookups and having long edit periods and short page loads onced cached, we can create subpages. Currently, used for Gem Store.

Before we ever hit the need for optimization, we would probably switch to a tooltip widget that generates a tooltip on-the-fly. The places where we list all skill facts on all skills is mostly reference tables that aren't edited often.--Relyk ~ talk < 02:54, 31 August 2017 (UTC)

I'd like to avoid having to split the lists into multiple pages if at all possible. The whole reason we'd be doing this is so that the information is available on a single page (obviously, it would still be better to have it, say, spread across 2 pages than 100, but still, it seems somewhat unnecessary), so I'd say that that should be the last resort. My knowledge of properties and subobjects is admittedly a bit limited, but if it was possible to dump the wiki markup for all the skill facts into a property and then just paste it in the lists, shouldn't that be easier to maintain than having to split the properties and queries into more sophisticated structures? I realize it's a bit crude solution, and I can imagine a couple reasons why it might not be the best option, but ease of maintenance doesn't seem to me to be one of them. I wonder, though, could we perhaps try to save that property for now, to see how fast or slow it would be? I don't think we should really consider the 13 seconds, since DPL is definitely not one of the options we'd want to use.

Anyway, do I understand it correctly that you'd want to make a property based on each individual skill fact and then reformat them in the skill lists? If it worked that way and it was fast enough, I can certainly imagine making a more concise version, perhaps only showing a row of icons for conditions, boons, CC and other effects, either without durations or perhaps even while having them on tooltip. That should definitely help with the description bloat a full list would cause... Or did I misunderstand you completely? ^^

18:19, 31 August 2017 (UTC)

Scream test

So I did a quick "let's see what happens" test, created Property:Has skill facts and annotated the skill infobox... and I saw a SMW warning triangle on the first page I encountered. I've quickly reverted it for now, but here's a sandbox version. My initial guess is that it doesn't like a parameter called "property", but I'll investigate. -Chieftain Alex 18:58, 31 August 2017 (UTC)

Okay found the issue. Skill facts are now generating. -Chieftain Alex

19:01, 31 August 2017 (UTC)

Quoting the Transclusion expansion time report times in the page source:

List of elementalist skills (pure SMW)	User:Noxx/Skill list (old) (SMW + DPL)	User:Noxx/Skill list (new) (pure SMW with facts)
3128 ms	14715 ms	6006 ms

It's not quite finished generating the skill facts yet, but this looks promising. -Chieftain Alex

19:14, 31 August 2017 (UTC)

I'm not quite sure which number were you reading, and I'm also not sure what the page was loading at the time, but when I looked at it, half the skills didn't load the facts at all and the other half still used DPL. ^^

Anyway, I updated all the templates used in the example to SMW properties, and the Parser profiler Real time usage times I'm currently getting in the edit window for cache reload are around 4.9-5.4 seconds. However, I'm not entirely sure if that is an acceptable time, if we could further improve it or go with a different route entirely. One other problem is that the skill fact properties categorize the lists according to combo fields and finishers.

17:56, 2 September 2017 (UTC)

https://imgur.com/a/nwuHS In firefox at least, you can right click inspect element on the main div#mw-content-text container, right at the bottom are some HTML comments you can view. Anything around 5 is acceptable. 30 is the max, beyond 30 the wiki rejects it with an error, beyond 15 I've already closed the tab and gotten bored. -Chieftain Alex

18:12, 2 September 2017 (UTC)

Combo skills

Hmm apparently this would cause any page querying for "Has skill facts" (if the subject has a combo finisher fact), to be added to the combo finisher category. This is unfortunate. -Chieftain Alex 20:39, 27 September 2017 (UTC)

The Agony Pages are an awful mess

There's a series of information on AR, Agony, Infusions, etc. Information is duplicated and it's usually unclear on where to find the information you actually want. These pages need a rework, or a merging, or an exorcism. Not sure which. Petition for help in restructuring all this. Here's a summary list and some info on all the pages to help make this a bit more obvious why/help restructure.

Agony (links to Agony Resistance through a disambig link and in-text link. Links to infusions through in-text)

Primary purpose: General overview of mechanic

Mechanics
- AR table
Suggested agony resistance table
Notes
Trivia

Agony Resistance (links to Aetherblade Retreat in a disambig; Infusion and Agony in-text

Primary purpose: General overview of counter-mechanic?

Acquisition
AR Table (duplicated once so far)
Maximizing resistance
- Cost efficiency<--HIGHLY VALUED SECTION (I think this section should be super easy to find.)
- Variations on infusion gearing
- Frugal (at the bottom for some reason)
External Links
Trivia

Infusion (links to agony resistance in text. Links to Agony Infusion primary article and I just added a link to the Agony resistance/maximizing resistance section.)

Primary purpose: discussing infusion types, including cosmetic and WvW infusions.

Infusion Types
- Agony Infusions
  - Cluttered paragraphs describing purpose and acquisition.
- Attribute Infusions
  - Less cluttered. Did pretty well for the amount of information they had to impart.
Notes
See Also
External links
Trivia

Agony Infusion (you thought we were done? links to infusion and agony resistance in text.)

Primary purpose: To discuss specifically the infusions used for agony and creating/obtaining them.

Acquisition
- Interesting little chart comparing crafting/TP/INFUZ-5959 costs. contains information that most people won't use, but probably have asked at one point or another.
- AR recipe list that could probably be summarized in a shorter method. Note that this is the only page that shows the recipe list format for creating an infusion. Other pages are less clear.
Notes on extraction

So I'm thinking make Agony shorter and move some information to Agony Resistance. Add a "primary article" link in the info's place. Information on Agony Infusion and Agony Resistance should be merged to one page, and Agony Resistance should probably be weeded down/reorganized significantly, if it is the one kept. So, thoughts? --Rain Spell (talk) 08:42, 5 September 2017 (UTC)

Agony - Move the "Suggested agony resistance" section to Agony Resistance.
Agony Resistance - Remove the "Table" section (agony is already linked in the first sentence). The "Maximizing resistance" is awfully long. I expect the following methods: (i) players without heart of thorns, (ii) all +stat infusions (i.e. all odd numbers: [12*+9, 6*+7]), (iii) most players use more than two weapons [8*+9, 8*+8, 2*+7]. Also, the summary at the top of "maximizing resistance" shouldn't link to legendary armor/weapons/trinket on every second line (remove all links).
Infusion - The sections are as I expected, apart from Agony Resistance which just needs a two line summary. I'll edit this now.
Agony Infusion - Fine in its current state. The article is meant to be about the +X infusion items, and provides an acquisition summary.

--Chieftain Alex

17:24, 5 September 2017 (UTC)

I went through the Agony Resistance page and cleaned it up some following your advice. I left a few of the more useful gearing methods, but removed like 5 of the others.--Rain Spell (talk) 19:23, 5 September 2017 (UTC)

I definitely think all articles need some restructuring and some descriptions needs to be elaborated. The Fractals of the Mists page probably needs to be looked at too. Intricity (talk) 21:13, 5 September 2017 (UTC)

Agony Resistance min/maxing

I had a go at tabulating and pricing up the different options. The quantities used for each option are in black. For the value of Laurels I've used the average value of a T6 bag of materials, and for the value of Badges of Honor I've used the value of a Badge of Tribute. I've then used the average of buy/sell TP prices for everything else to figure out a value for each used item (blue), and calculated the current value of the option (also blue). The agony resistance is in red, and the stat bonus in green. This isn't meant for use on the article ;)

Option	AR	+Stat	Mighty WvW Infusion	Mighty +5 Agony Infusion	Mighty +7 Agony Infusion	Mighty +9 Agony Infusion	+5 Agony Infusion	+7 Agony Infusion	+8 Agony Infusion	+9 Agony Infusion	+10 Agony Infusion	Base price (g)	Additional weaponset (g)	Notes
Average item value (g)			7.02	14.51	31.38	75.20	0.50	1.90	4.36	7.95	16.13
Efficient	150	0							12	6		100.1	8.7	Uses +8s for weapons.
Alternative efficient	150	0						2	8	8		102.3	3.8	Uses +7s for weapons. Needs only one extra weaponset to make it worthwhile
Mighty Fractal	150	90			6	12						1090.7	62.8	Only +5s, +7s and +9s are available for Mighty etc infusions.
Free accounts	150	0								10	6	176.3	15.9	16 slots since cannot attune rings. Uses +9s on weapons.
Frugal	150	0							3	14		124.4	8.7	17 slots since not infusing backpiece. Uses +8s on weapons.
Minimalist	130	0						14	4			44.1	3.8	Plus 20 from Anguished Tear of Alba consumable and Mistlock Singularity. Uses +7s on weapons.
Alternative minimalist	135	0						9		9		88.7	3.8	Plus 20 from Anguished Tear of Alba consumable. Uses +7s on weapons.
Mighty Raider (via Fractals)	90	90		18								261.1	29.0	AR is by accident, interested solely in Mighty etc bonuses.
Mighty Raider (via WvW)	0	90	18									126.4	14.0	As above but cheaper, interested solely in Mighty etc bonuses.

Thoughts:

Much to my surprise, the option called "Efficient" is a load of crap if you want more than one weaponset (e.g. your weaponswap set). Even two weaponsets makes it worthwhile. We could remove the "Efficient" option, in favor of "Alternative efficient".
+stat WvW option isn't mentioned, and you could save 135g compared with the Mighty +5 Agony Infusions.
If a full set of ascended armor (6 pieces) costs 420g, 3 weapons (1x 2h, 1x 1h, 1x offhand) cost 220g, and trinkets are free, that gives a total of 640g. It'd be cheaper to craft a separate Raiding set and use +5 stat infusions (640g + 261g = 901g ... or 640g + 126g if wvw), than to upgrade an efficient 150 AR set into a 150AR +90 stat set (1091g).

--Chieftain Alex 18:31, 6 September 2017 (UTC)

The "Efficient" option is named such because it requires the least amount of +1 infusions to craft a full set. It was originally named "Cheapest" but that got contested with the current "Frugal" setup. In the end I decided to not use "Cheapest" due to how subjective it is. Should we only count the cost of the infusions? Should we consider the cost of each infusion slot as well? Or is there some other factor we should consider before we can call it the absolute cheapest?

I do acknowledge that the "Alternate efficient" is the actual efficient setup, but the current "Efficient" setup deserves to remain on the page too, although probably under a different name. Intricity (talk) 23:16, 9 September 2017 (UTC)

Progress Report

Detailing how everyone has altered the pages and what might still need tweaking:

Agony

Not too many changes were made (or were seen as unnecessary)
- Clarified application methods slightly.
- Now links to both AR page and Cairn's AR
Certain paragraphs sound or seem dated, such as paragraphs detailing how Agony is meant mostly for Boss fractals.

Agony Resistance

Lots of cleaning was done.
- (re)moved chart detailing agony elsewhere.
- Refined notes and equations. Someone should probably double check the numbers with Alex's.
  - I think it'd be interesting to have these be display on click. (those little hidden box things? idk) There's so many combinations when most people just want to know the cheapest option period, or how to if they're non-HoT.
Will probably need someone to run through it for spelling/grammar/continuity.

Infusion

With the initial paragraphs cleaned and some information hidden, this page looks pretty organized now. I can't find anything more to fix.

Agony Infusion

It looks good?
Added a disambiguation link to the Agony Resistance/min-maxing section.

--Rain Spell (talk) 05:54, 8 September 2017 (UTC)

Rewards template

This may be a crazy idea that might not work, but what if we had a template for rewards similar to gathering? This idea is half inspired by trying to hunt down where some items came from, ie story rewards, and partially by the challenge rewards conversation on Talk:Nightmare Fractal and I think also some events but I might be getting some Halloween stuff mixed up there. The hope is that it would make it easier to make sure item pages have all their sources, as I think pretty much it's been listing things manually, which often means things are missing. - Do_odleplex 23:42, 5 September 2017 (UTC)

You mean to keep track of items you get from shaky chests specific to special monsters/events? Would it also give placement for items received from map/event rewards? e.g. a Fragments of the Solid Ocean, Kournan Coin, or Homespun Blindfold? I'd say it has use. --Rain Spell (talk) 02:46, 6 September 2017 (UTC)

Map rewards would stay as map rewards and documented on that page since those are triggered by the map and not a specific event and would blow up the page. If there is something dropped specifically from the bouncy chest at the end of a specific event then sure, but I honestly can't think of any item other than the Invisible Mushroom Spore variants that would apply to, unless the Invisible Boot Box actually drops that way(which I've heard could be true). The "might not work" part is actually making the template work. =/ If it is possible though, I was pondering maybe using the Hero achievement panel icons to indicate personal story rewords, with Living World story step/Fractal achievement icon to indicate those. If the event items are just what I listed above, maybe use the event icon? - Do_odleplex 19:05, 6 September 2017 (UTC)

All these templates already exist. "Rewards" is too abstract for a template and many things may not be considered a "reward". The template should describe the mechanic being used to reward the player. The stupid, easy way is to create a template for each source type, hence {{event rewards}}, {{contains}}, {{drops}}, {{gather}}, {{salvages into}}, poorly named {{reward}} for story rewards, etc. Because 99% of rewards take the form of items and currency, this isn't too hard to do. Once we decided what our templates look like, we can start adding source type information and aggregate that information on the desired page.

Right now, editors use whatever template happens to work because they can all be used for describing the source of items. We do want the ability to ask what source types drop what item types because that's powerful and useful to players. Our approach has been ad-hoc for the most part.--Relyk ~ talk < 01:00, 10 September 2017 (UTC)

Champion bags crafting materials drop table

I've seen many pages are missing information about available drops. At the same time, Noxious Seed Pod has very nice tables with available crafting materials. What about converting these tables to templates and including them in all pages? Something like "Champion bags material drops|rarity" (rarity = basic, fine, masterwork, rare, exotic). I've been opening a lot of champion bags lately and all the bags I opened gave me exactly these materials. The F. Prince (talk) 14:23, 13 September 2017 (UTC)

Using the wiki's Sitenotice to give advice

Hey folks, I'm looking for some feedback on a small project I've been working on. You can Refresh the pages to see them cycle.

Current project page: User:Greener/Sandbox4
Current preview page: User:Greener/Sandbox3

My intentions were to run this as a banner across the wiki for a week prior to the PoF launch, i.e. the 14th to 21st. I've run into some roadblocks which currently leave me not wanting to proceed, but other perspectives on it may help.

This project will be hijacking the wiki's Sitenotice banner, which splashes across the top of all pages when people visit the site.
- We've typically reserved the Sitenotice for important information.
- Dismissing the Sitenotice seems to not always be available for visitors, typically those who are not logged in as a user.
The Sitenotice caches itself for 10 minutes, which means that the advice will not cycle for 10 minutes for anyone.
- Showing the same piece of advice on every page for 10 minutes seems more obtrusive than helpful.
I've created a page which shows all the advice at once, User:Greener/Sandbox2
- I'm terrible at design, and I'm not happy with how it looks. Help would be appreciated.
If this project does proceed, then I'd like to make sure I've hit solid points.
- Let me know if there's anything I may have missed, or if something needs to be reworked. I'd like to keep the number of tidbits relatively prime to 10, so 9, 11, or 13 items would be good.

Thanks in advance. G R E E N E R 20:35, 14 September 2017 (UTC)

The other thing to remember is that anonymous (IP) users cannot dismiss the sitenotice. -Chieftain Alex

20:38, 14 September 2017 (UTC)

I really like the idea! It'd be cooler if the whole caching thing didn't happen. I don't know much about coding and that, but I think changing the box color so it's more colorful would be nice.--Rain Spell (talk) 06:17, 15 September 2017 (UTC)

While the concept behind the idea sounds worthwhile, I am extremely reluctant to train users to ignore sitenotice. Even for inexperienced wiki users, sooner or later they're going to wind up seeing every tip. What if we put it on Main Page instead? Slip it right in between 'Welcome to the official...' and the featured and news boxes. - Tanetris (talk) 17:48, 15 September 2017 (UTC)

I think putting either here on this page or on the Sandbox might be better, mostly because it's these two places people are more likely to go for help. - Do_odleplex 17:53, 15 September 2017 (UTC)

My goal isn't to reach out to those currently looking for help, but instead to tap people on the shoulder and pass on a tidbit of info for them to do with what they please. I'm also aiming for this to be a temporary PSA.

I'm binning the idea of using the sitenotice, and will see what I can hack onto Main Page/editcopy. Nice idea, Tanetris. G R E E N E R 18:04, 15 September 2017 (UTC)

Won't we be doing a countdown banner anyway, if so, why not stick a tip in there too? -Chieftain Alex

18:49, 15 September 2017 (UTC)

Thanks for grabbing this one by the horns, Alex. I think I got caught up in trying to make it just right, and ended up spinning my wheels instead. G R E E N E R 15:07, 17 September 2017 (UTC)

#time

So Greener, out of interest, are you telling me that 22 Sep 2017 16:00 doesn't show "22 Sep 2017 16:00"?
Or was it only the 22 Dec 2024 01:57 bit doesn't show the UTC time as expected? -Chieftain Alex 17:31, 19 September 2017 (UTC)

The format that you had going was counting based off of 16:00 local time, whether I was logged in or not. So the # of days would change at 16:00 local instead of 16:00 UTC like it should. My guess was that if it was doing this for me across multiple browsers, then it was doing it for others. Now blaming the truncating of information leading to some counting joys. G R E E N E R 18:34, 19 September 2017 (UTC)