Guild Wars 2 Wiki talk:Community portal/Archive 10

From Guild Wars 2 Wiki
Jump to navigationJump to search

Vista-file-manager.png
Archive

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.

NPC audio widget

Stephane mentioned this in on User:Stephane_Lo_Presti/News/2014-13-03, we already have the Widgets extension. fr:Widget:SoundCloud with an example on fr:Journal_de_Scarlet_Bruyère#Lire.--Relyk ~ talk < 08:54, 12 April 2014 (UTC)

Stephane said that these shouldn't include music, but anything on ArenaNet's SoundCloud should be fair game, right?
Incidentally, is there any way to upload mp3 files? It would be nice to have 30-second previews of the songs on the soundtrack, to go on the Soundtrack page. --Santax (talk · contribs) 13:06, 1 May 2014 (UTC)
Yes, .mp3 just needs to be added to the list of allowed file types. Anything can be allowed; whether the wiki is able to do stuff with those files is another matter. We experimented with it on GuildWiki some years back, since .ogg is part of the standard MediaWiki set (or something), but not all browsers can play that out of the box. Not sure about .mp3 format. Vili 点 User talk:Vili 22:24, 1 May 2014 (UTC)

World Boss Timers

I'm hoping we can add a SMW-tool/widget/template that will make it easy to show the times of the schedule bosses (Megadestroyer, Tequatl, ...) and keep it synchronized across articles, even as ANet tweaks with the schedule. For example, there would be an article that stores the data of the scheduled appearances and a template that pulls that data. Thus, Megadestroyer could show that boss' five appearances; boss would also show that (in addition to any other appearances); and even Trait guide could include the times that people can unlock various traits. If ANet tweaks the timing (e.g. MegaD appears 8x/day instead of 5), we just have to update the data article. We've used something like this for daily (and Nicholas, @GWW and GWiki).

Thanks. – Tennessee Ernie Ford (TEF) 14:53, 17 April 2014 (UTC)

http://semantic-mediawiki.org/wiki/Help:Recurring_events
{{#set_recurring_event: Event
| property = Has time
| has title = <--Jungle Wurm-->
| has group = Boss spawn timers
| start = April 15, 2014 <--7:00 pm-->
| unit = day
| period = 1
}}
The title and time in <-- --> are the variables between bosses and specific spawn times. We will need to maintain the start date every few months: the number of future events calculated is limited to 100 by default without an end date; by specifying an end date, this can be increased to a maximum of 500.
Unfortunately, it looks like we need to upgrade to SMW 1.9 in order to get the features to make this usable for us. Last I heard, MW/SMW upgrades were the next thing on Justin's schedule for the wiki. Hopefully that can happen soon. —Dr Ishmael User Dr ishmael Diablo the chicken.png 16:13, 17 April 2014 (UTC)
I've decided that, given this wiki's history, SMW must stand for Some More Waiting. — snogratUser Snograt signature.png 16:19, 17 April 2014 (UTC)
Is there something we can do besides Some More Waiting? The content is new and people are very confused about when/where. I'd like to point folks to the wiki and particular to something easier to read than the original blog post. I realize that what you've proposed will be better (perhaps much, much better), but why won't the GWW/GWiki Traveler Nick tricks work in the meantime? Thanks. – Tennessee Ernie Ford (TEF) 17:51, 17 April 2014 (UTC)
Question: Do we want this semantic data tied to the boss, the event, or the meta event? —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:29, 17 April 2014 (UTC)
Always the event.--Relyk ~ talk < 20:11, 17 April 2014 (UTC)
You sure? For some of these bosses, the full meta-event chain still runs when the boss spawns, e.g. Modniir Ulgoth starts from Stop the centaurs from retaking their camps. Do we put the timer on that event, or on the final event? It's the first event that actually spawns on the timer, not the final one. —Dr Ishmael User Dr ishmael Diablo the chicken.png 12:33, 22 April 2014 (UTC)
I agree meta event is better. meh--Relyk ~ talk < 22:19, 24 April 2014 (UTC)
Got a dirty demo up on Guild Wars 2 Wiki:Sandbox. In order to make sure it updates properly, though, we'll need to install mw:Extension:MagicNoCache. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:02, 17 April 2014 (UTC)
Or you just include {{time}} to make the cache go away :P poke | talk 18:17, 19 April 2014 (UTC)
What's that? DPL? Oh, I'd forgotten we still had that around. :) —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:46, 19 April 2014 (UTC)
I have done some world event timer related stuff in my sandbox. I don’t think going the SMW route here gives us *any* benefit but makes it actually way more complicated. I’m still polishing things, but the basic functionality is there. poke | talk 13:50, 22 April 2014 (UTC)
The benefit of SMW is that we can store the information in one place and query it in other places, and then we can easily update the base data with a single edit if Anet ever changes the schedule. —Dr Ishmael User Dr ishmael Diablo the chicken.png 14:32, 22 April 2014 (UTC)
Well, there are certain facts that destroy this idea though:
  • Ambiguity where to store the data (meta event, boss event, pre event? Also what about Triple Trouble where there are three boss events)
  • Permanent maintenance requirements: “We will need to maintain the start date every few months” as you have said yourself
  • Rotation is daily and actually resets at midnight PDT, making the events not recurring based on a simple rule
  • Standard boss rotation is paused by those super world bosses, which have a fixed time themselves, so that will make very complicated rules if it’s even possible to specify it with SMW.
  • The rotation is always updated as a whole: If a new boss is added in the rotation, the whole rotation will update. Same with when a fixed-time super world boss changes. With SMW, the rotation information is spread across many different pages, so all those would need to be updated and for those complicated formulas, they would all have to be re-specified which likely isn’t a simple task.
On the other hand, the simply time-cycle solution is a lot more flexible, is specified in a single location and is not limited to “nice” recurring rules. Also: It has a incredibly low overhead. Only a single template is involved, which results in a way better performance than an SMW queries over a number of event pages that all have some bits of information. And that is absolutely critical if you want to have a real-time countdown without caching. poke | talk 14:48, 22 April 2014 (UTC)
"Ambiguity where to store the data" Good point, I was already thinking that it would be better to reverse my original idea: store it all centrally on World boss and query it on the boss/event pages. This addresses your last point as well.
"Permanent maintenance requirements" That's actually irrelevant now, since I decided not to use the SMW recurring event functionality. There's no maintenance needed with my current example.
"Rotation is daily and actually resets at midnight PDT, making the events not recurring based on a simple rule" Actually, that does make them recur based on an extremely simple rule - they always happen at the exact same times every day. Did you look at what I'd done on Defeat the great jungle wurm? Each spawn time during the day is specified explicitly. —Dr Ishmael User Dr ishmael Diablo the chicken.png 15:05, 22 April 2014 (UTC)
I've updated the sandbox to include all timing data (subobjects) in one place. I also wrote Widget:TimerJS to provide live countdown functionality.
The next thing I'll do is add some normalization: have each spawn time object refer to a "boss event" object that can hold data like boss (page), map sector (page), nearest waypoint (text), etc. —Dr Ishmael User Dr ishmael Diablo the chicken.png 20:46, 22 April 2014 (UTC)
Looks interesting. Will keep an eye on the progress :) poke | talk 21:28, 22 April 2014 (UTC)
Update: table now auto-collapses to only the active event + 1 hour. I want to add a button/link that lets you expand the full table, but I'm not sure how with the way it's currently coded.
I'd love more feedback on this, I'm still terrible at the presentation side of things. TEF, you're the one who started this whole mess - you still around? —Dr Ishmael User Dr ishmael Diablo the chicken.png 03:05, 1 May 2014 (UTC)
I personally would rather have a wiki link (to the zone or part of the zone) given for the location than a game link to a waypoint, but I can see the argument for either way. For people like me that know where every boss spawns, the in-game link is useful, but to those who are new to world bosses, it may be more helpful to see the name of the zone or whatever.
The color scheme could also use some work, but of course it's a working demo. Yellow highlight is pretty glaring...
Also, a usability question because I don't understand fancy wiki stuff: to get this to work on some other page, would it require copying that entire massive block of code, or can it be made into some simple template-type thing for transclusion? Like, say, {{world boss timer}}. That would be hot. Vili 点 User talk:Vili 03:43, 2 May 2014 (UTC)
I can add the area/zone information easily - it's already in the metadata subobjects, so I would just need to modify the query output to display it. To use on other pages, you wouldn't need any of the #subobjects - those simply define the semantic data on whatever page they're on, but they can be queried from anywhere. I'd had a thought a couple hours ago about adding a "next spawn time + countdown" to each of the bosses' pages. I should be able to get a demo of that tomorrow. —Dr Ishmael User Dr ishmael Diablo the chicken.png 04:03, 2 May 2014 (UTC)
I just had an idea while out and about - it would be really cool to have a mobile app that functions similar to the sandbox demo, showing what boss is up and which ones will be soon, adjusting for whatever the user's timezone is. Adding temple timers on top of that would be even better, but I'm not sure if anyone has managed to make those work properly yet. Vili 点 User talk:Vili 21:32, 2 May 2014 (UTC)
Temple events aren't anything special in the megaserver, so timers for them are impossible. —Dr Ishmael User Dr ishmael Diablo the chicken.png 21:34, 2 May 2014 (UTC)

Implementation

I've implemented this in 4 parts:

Still need help with the styling/formatting, if anyone wants to assist. —Dr Ishmael User Dr ishmael Diablo the chicken.png 01:13, 3 May 2014 (UTC)

Looks great :D
It could just be my browser (I refuse to update it), but i reckon using expandable instead of mw-collapsible mw-collapsed collapses much more smoothly. (scroll bar changes length in quite a jagged way for the mw version.)
Again, possibly just me, but the chat links extend over the edge of the table when you click on them, perhaps increase table width/decrease size of chat link box (likely unpopular with someone..)
The yellow row works fine: very bold, very obvious. When I saw the light-blue row immediately beneath, my first thought was that it was the row formatting odd/even pattern, currently too subtle imo. Perhaps another yellow? (#F7FF89 ?) -Chieftain AlexUser Chieftain Alex sig.png 01:33, 3 May 2014 (UTC)
I am not getting any issues with scroll bar, but the chat links do this: http://puu.sh/8wRWy.jpg . Functionally this isn't a problem, but it is definitely ugly.
Loving the templatization though. Vili 点 User talk:Vili 02:05, 3 May 2014 (UTC)
true, only seems to be a minor issue in Opera 12.17. IE11 seems fine, so I guess chrome/firefox will be ok too. Still, optimal if everything works great... so I'd still recommend switching to poke expandable. -AWB Alex User AWB Alex sig.png 02:10, 3 May 2014 (UTC)
@Vili: Fixed the width defined in Widget:Game link for the input boxes. That's something I'd been meaning to correct for a while.
@Alex: I don't see any jagged scrollbar stuff at all in Chrome. I'd rather stick with the MW-defaults. —Dr Ishmael User Dr ishmael Diablo the chicken.png 02:53, 3 May 2014 (UTC)

Feedback namespace

Was there ever any discussion in having something like the Feedback namespace from GWW on GW2W? It was closed in favour of the official forums' suggestion forums, which itself was a temporary solution until "a better, more organized way [...] than using the forums" could be provided. None ever came, and now the suggestions forum is closed as well. I think that the Feedback namespace, like the Guild namespace, probably brought a lot of users to GWW who otherwise wouldn't have bothered. Unlike the Guild namespace, however, it was comparatively low-maintenance, and a Feedback namespace on GW2W might draw in new editors at a low cost in terms of time required to maintain. --Santax (talk · contribs) 22:05, 24 April 2014 (UTC)

The suggestions forums were replaced by the CDIs.--Relyk ~ talk < 22:13, 24 April 2014 (UTC)
"at a low cost in terms of time required to maintain" If you don't maintain it, then it turns into a quagmire just like the Suggestions forum. No, this would be worse than a Guild namespace, IMO. —Dr Ishmael User Dr ishmael Diablo the chicken.png 22:38, 24 April 2014 (UTC)
jesus christ no thanks to feedback space, even worse than the guild space. -Chieftain AlexUser Chieftain Alex sig.png 22:52, 24 April 2014 (UTC)
(Edit conflict) agreed with Dr ishmael, the wiki is for documenting the game not documenting randoms suggestions.-User Zesbeer sig.png Zesbeer 22:53, 24 April 2014 (UTC)
The only actual benefit of the feedback namespace was that ANet members could (theoretically) openly discuss things without restricting the content to GFDL. I had tried to get this licensing wiki-wide when the wiki got active but there wasn’t really much interest in taking it further. Now it’s too late for that, so we would again have to have a “feedback” namespace. I also highly disagree with going that route though. No thank you. The benefits we actually got from the feedback namespace were minimal, and the maintenance cost was rather high. poke | talk 23:17, 24 April 2014 (UTC)
The main benefit of the Feedback namespace on GWW was giving certain users a place to hold pissing matches game design debates that was out of sight and out of mind from mainspace articles and talk pages. Vili 点 User talk:Vili 04:25, 25 April 2014 (UTC)
It did have some comedy value (favourite title) -Chieftain AlexUser Chieftain Alex sig.png 07:56, 25 April 2014 (UTC)
(Edit conflict) No, thanks. Players can already make suggestions using the forums, so I don't see an issue that needs resolving. (The folder called "Suggestions" was removed and players were encouraged to place their ideas in the area-specific folder instead.) If there was an issue, the wiki is a bad tool for resolving it — wikis are about documentation, all players have userIDs for the forum (but few have wiki IDs), and the Feedback space required more maintenance than most people seem to think.
I do think the GWW Feedback space served an important purpose: the devs always said they read it and I believe that many of the ideas there made their way into the game. But that need doesn't exist any longer. In particular, as noted by Relyk, the CDI provides an even stronger mechanism for actual Feedback (as opposed to players offering suggestions in a vacuum, without any idea of whether their ideas were being read, let alone being considered). – Tennessee Ernie Ford (TEF) 08:14, 25 April 2014 (UTC)

outfit documentation

I've started updating all the outfits, and I want to get consensus before I continue. The new system works like this:

  • You buy an outfit from the store and you get a container.
    • The container contains a consumable and a gizmo.
      • The container and consumable have the same name.
      • The consumable is an outfit skin transmutation - when you us it, it applies the outfit skin to your outfit slot for free and unlocks the outfit in your wardrobe.
        • This replaces the 4 separate town clothing pieces from the old system.
      • The gizmo is a costume brawl toy that equips a bundle with costume brawl skills.
        • This replaces the toy weapon from the old system.

Updating the container page and the toy->gizmo page are the easy steps. The consumable having the same name as the container is the problem, and there are two options: A) keep the container pages where they are, without qualifiers, and create "X (consumable)" qualified pages for the consumables; B) move the container pages to "X (container)" and create the consumable page at the non-qualified name.

Option A is the easiest, and it's what I've done for two outfits so far:

But is that the best solution? Moving the container page will require updating a lot of links, but otherwise wouldn't be all that troublesome. Since there's no obvious "right" choice, I don't want to make this decision on my own. —Dr Ishmael User Dr ishmael Diablo the chicken.png 17:51, 28 April 2014 (UTC)

Right up until you said "updating a lot of links", I would have said that the outfit that you wear is more important than the container and so it should be "<outfit>" + "<outfit> (container)"... (method B)
except nobody likes fixing redlinks - even if we're bot fixing them. Either choice is fine by me, depends on difficulty of fixing loads of redlinks tbh :P -Chieftain AlexUser Chieftain Alex sig.png 19:45, 28 April 2014 (UTC)
The consumable, and more importantly the gallery that will be on that page, is far more important and interesting to players by far than the container they get from the gem shop. Therefore, I think it's worth the effort to update the links. I will take on that task after I work through armor stuffs if nobody else has done it by then. Psycho Robot (talk) 19:56, 28 April 2014 (UTC)
There wouldn't be any redlinks at all, Alex, it would simply be a matter of making sure the existing links are pointing at the appropriate page. Links from Gem Store should point at the container, since that is the item you get when you make the purchase; links within the context of the wardrobe should point to the consumable/skin.
There aren't very many links to these pages at all (okay, I exaggerated before), I can handle them. Most of them are backlinks from the old clothing items. —Dr Ishmael User Dr ishmael Diablo the chicken.png 20:06, 28 April 2014 (UTC)
I don’t have a real opinion on this, but I would suggest putting the images on the gem store item too, and keeping that as the default. After all, the gem store item is what most will get first, and the gem price there is definitely of interest. Also, the text in parentheses should be more specific, e.g. “Witch's Outfit (outfit)”, because a container is technically a consumable too. If we decide to go the inverse, then the parentheses should be something like “Witch's Outfit (gem store)” or something. poke | talk 21:07, 28 April 2014 (UTC)
Containers and consumables are different item types, I've explained this before. They're similar in that you double-click to use them, but containers spawn other items in your inventory while consumables give you an effect or some amount of currency. —Dr Ishmael User Dr ishmael Diablo the chicken.png 21:25, 28 April 2014 (UTC)

(Reset indent) Alright, looks like we're at a stalemate. One argument is that the outfit/skin is most important because that's what people are actually interested in, while the other argument is that the container is most important because that's what you get directly from your purchase. Since it's already been two weeks since the update, I'm not going to wait much longer before plowing forward with this, but I'll leave the discussion open for a few more hours. —Dr Ishmael User Dr ishmael Diablo the chicken.png 14:59, 29 April 2014 (UTC)

As I said, I don’t really care either way, but we should put some information from the other to the primary article too whatever that ends up being. I.e. when we use the actual consumable, put in some gem store stuff too; if we use the gem store item, put in some outfit stuff (e.g. screenshots). Looking from that direction, it might make more sense to have the gem store item as the secondary as it has less unique information. poke | talk 15:25, 29 April 2014 (UTC)
The consumable for the outfit is more important; we would have the gallery on that page. Only gem store information required on the consumable page is the cost of the container.--Relyk ~ talk < 17:26, 29 April 2014 (UTC)
go go method B. -Chieftain AlexUser Chieftain Alex sig.png 17:48, 29 April 2014 (UTC)
This is the way I was leaning, mostly so that Outfit#List of outfits will be unqualified article names. I probably won't be able to get on this until tomorrow, but I've got all the API data ready. —Dr Ishmael User Dr ishmael Diablo the chicken.png 21:40, 29 April 2014 (UTC)
All done. We actually seem to be lacking galleries for most of them, which sucks. —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:51, 30 April 2014 (UTC)

disseminating trait unlock information

We should probably do this. What I mean is adding a note to pages like A Light in the Darkness, Harathi Hinterlands, Goff's Loot, etc. stating that completing that content unlocks a trait. I tried writing one for ALitD, but I couldn't come up with a wording I liked. What I had:

Completing this story step unlocks trait I in the first trait line.

Help? —Dr Ishmael User Dr ishmael Diablo the chicken.png 21:13, 30 April 2014 (UTC)

my suggestion: "Completion of this step in the personal story unlocks trait I in the first trait line."
in other news, ALitD has two navs, two notes sections and is hideously long.. -Chieftain AlexUser Chieftain Alex sig.png 21:18, 30 April 2014 (UTC)
I brought this up on the trait talk page but agree. ill work on it when I have time (which is to say I have no idea when)-User Zesbeer sig.png Zesbeer 21:29, 30 April 2014 (UTC)
For traits awarded through personal story steps, can't it just be added to the rewards template? As for adding it to Harathi Hinterlands, I'm not sure its important to do that. Players wanting to unlock the trait will go to that trait's page and read about how to unlock it. Players wanting to unlock all traits will go to the trait page and read about unlocking all of them there. I don't think that a player will, at any point, go to Harathi Hinterlands with the expectation to read about the traits they can find there. It's a backwards way of thinking. Psycho Robot (talk) 21:50, 30 April 2014 (UTC)
good point on putting it with the rewards stuff, I was thinking it would be a good idea to add it to the reward section since it won't place it at the end of the stupidly long page. Whether its the same reward for every personal story of the same lvl idk, but if it is, by all means add it to the template. -Chieftain AlexUser Chieftain Alex sig.png 21:58, 30 April 2014 (UTC)
@Alex: That completely did not address the part I was unhappy with, but that's probably because I didn't specify. I don't like the last part, "trait I in the first trait line." It feels too non-specific, even though I know it needs to be non-specific due to these unlocks being the same for all professions.
@Zesbeer: I didn't post this because I need help making the edits, I just need help with the wording. But thanks for the offer.
@Psycho: They may not go to a zone article specifically looking for information about traits, but that doesn't mean it's backwards thinking. Most players aren't going to go to a personal story article looking for trait information either. This is about spreading the information around so that people browsing the wiki will see it. We can include a link back to trait guide so they can then find all the trait information.
@Psycho/Alex: There are only 6 PS steps that unlock traits. That's too few to merit any changes to the template. We can just list it manually. —Dr Ishmael User Dr ishmael Diablo the chicken.png 22:06, 30 April 2014 (UTC)
Still, but it in the rewards section of the page - not hidden with the notes.
apologies for being useless at wording ;) does it show anything ingame when you unlock the traits? or is the difficulty in referring to many traits with a generic term? (presumably ingame, if you're a guardian, it shows "you've unlocked trait 1 in the virtue line" or something?) -Chieftain AlexUser Chieftain Alex sig.png 23:08, 30 April 2014 (UTC)
Of course I agree with putting it in the rewards section, just not that it should go in the template. In-game it shows you the specific trait that you unlocked, since it happens to a specific character who is of a specific profession. I'll try to remember to get a screenshot when I get the next one on my new character (who I haven't added to my userpage yet, shame on me!). —Dr Ishmael User Dr ishmael Diablo the chicken.png 23:21, 30 April 2014 (UTC)
trait reward. Maybe the trait pages need an acquisition section since there are multiple ways to obtain them now?--Relyk ~ talk < 23:30, 1 May 2014 (UTC)
You beat me to it - didn't get any traits last night. There's also an icon in the notification area: Trait unlock.png, that appears first, you click it and Relyk's dialogue pops up. —Dr Ishmael User Dr ishmael Diablo the chicken.png 23:57, 1 May 2014 (UTC)
Kind of hard to beat a picture taken two weeks ago :P--Relyk ~ talk < 00:00, 2 May 2014 (UTC)
My suggestion to this would be.... First off all, I think it would be easier to list all traits for all classes on a single page. This would require a change on the class pages where they refer to traits:warrior (or traits:ranger , depending on wich one). This would make it easier to make the links. Such a page can extract the data from a category list (using a template). This category would be traits. Each Trait should have an internal number. I'm thinking bout 101 for the numer I trait from the first traitline of a class. so e.g. Defy Pain would get the number 311 (warrior traitline 3, traitskill 11). so that means that Empathic Bond would also get ID 311. This ID can be hidden in the info box. The next thing would be a template, reading all the ID's, showing the right Trait unlock.png on the activity page (storymode CM or eventpage for balthasar temple) by putting in something like {{traittemplate|311}. After clicking the icon you get to the traitpage top, where the index would help you continue to your classes trait. Hope you'll understand what I mean. I dont have the skills to make the template I am mentioning, but I think it can be done within wiki code by a skilled programmer. It would require some programming skills, but if in place, the actual editing is easy and flexible.195.240.63.18 22:51, 13 May 2014 (UTC)

loot equipment

Sparked by the discussion [[Talk:Clerics Iron Greatsword of Venom|here]], I did this:

  • User:Dr ishmael/Iron Greatsword (loot A) - fine (66 variants)
  • User:Dr ishmael/Iron Greatsword (loot B) - masterwork (41)
  • User:Dr ishmael/Iron Greatsword (loot C) - rare (29) and exotic (15)

(later additions)

  • [[User:Dr ishmael/Iron Greatsword (loot D)]] - all 151 variants
  • [[User:Dr ishmael/Krytan Greatsword]] - all 46 variants

The splits are necessary because the server blows a 502 if there are more than ~75 variants on a page.

Is this a good thing? Do we want to do this for all loot equipment, so it can finally be documented on the wiki?

If so, how do we handle the pagename qualifiers? Should we complete the split by rarity - instead of combining rare+exotic - to get straightforward (fine loot)/(masterwork loot)/etc. qualifiers?

—Dr Ishmael User Dr ishmael Diablo the chicken.png 21:38, 26 June 2014 (UTC)

I think it would be within the purview of the wiki to document random loot "eventually", although as we know, historically and continuing today there's no particular interest in this sort of information + it's a lot of work. But it's something we "should" document.
It's a shame that it's not possible to combine all variants into a single page, since that would be the simplest and most logical way to do it...I'm curious though, since when searching the trading post for e.g. Greatsword, there are always some that seem to not exist (no supply) or that are not obtainable anymore. For example, this 80 exotic "Greatsword" with no affix at all. There's exactly one available, so it exists, but this type of loot I don't think is obtainable anymore. Maybe we could pare down the variants by eliminating these types of random loot?
It's ugly and inconvenient to have multiple articles split by rarity, for what is essentially just one item, but I can't think of a better fancy way to do it right now. Now, what we *might* do instead is ignore the {{item variant table}} and instead just make it a plaintext table. This is less whizbang-impressive but would easily allow us to do just one page with every single variant on it (unless I misunderstand the 502 error). Considering the low priority and demand for random loot information, this might be the way to go. At the least, it might be the first step to collecting this information; we can worry about the presentation aspect for 10,000 items later. Vili 点 User talk:Vili 22:16, 26 June 2014 (UTC)
if we're of the opinion that the random loot versions shouldn't be popping up in general smw queries, then we could just switch off the subobjects for these cases. Fixing the presentation on 10000 items would be awkward and if we can avoid that, i'd prefer that. -Chieftain AlexUser Chieftain Alex sig.png 23:03, 26 June 2014 (UTC)
We wouldn't turn off subobjects, we would use a separate template like mystic recipe.--Relyk ~ talk < 00:17, 27 June 2014 (UTC)
@Vili: I'm already doing some filtering, as I noted on the other talk page. The two main filters are 1) the item has to have "Iron Greatsword" as the base item name, and 2) exclude the crafted versions. So the generic "Greatsword" items (there are 8 of them) are already excluded. About the 502 - yes, that's mainly due to the time required to process 75+ subobject templates, and it would probably be fine if we used direct formatting instead of templates. But as Alex points out, that would be very annoying to modify in the future, so we should stick with templates.
@Alex/Relyk: Why would we not want to annotate this? Isn't that what you two are building toward with the query forms - being able to search for anything in the game? —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:43, 27 June 2014 (UTC)
I stripped down the variant template to get {{loot variant table row}} and now all 151 variants can fit on a single page (added link to page D to first post). —Dr Ishmael User Dr ishmael Diablo the chicken.png 20:47, 27 June 2014 (UTC)

(Reset indent) Time to restart this - I added a second example for Krytan Greatsword that has 1/3 the amount of variants. Alex and Relyk haven't explained why we wouldn't annotate these variants, and I've reduced the template's footprint enough that splitting is no longer necessary. Is there any reason I should not go ahead and add these tables to all the loot item pages? —Dr Ishmael User Dr ishmael Diablo the chicken.png 20:02, 7 July 2014 (UTC)

The problem of the server stop processing is related to the time it takes to display the page (due to the many templates each subobject has to go through), right? The amount of subobjects on a single page is not a problem? In that case, it makes no sense *not* to store every single item. Alone for the query-ability, both for the query forms but also for the chat link search, we should have every item exist somewhere as a (sub)object on the wiki.
If it works with that reduced template, I think we should go for it. However, I would like you to test it a bit further, so we can be sure it supports a bit more than exactly that number of items (just to be future-proof ;) ).
That single page does however raise a different issue for me, and that’s the visual presentation: That table is annoyingly long ;D I mean, I could live with it since it’s just a random loot item and people likely don’t care too much about it anyway. But I would still like to look for improvements we could make to get it a bit more concise. Since all those stats are generated automatically anyway, one way I could think of is to just keep the actual stat numbers off the page. But that would require other pages (e.g. the prefix pages) to actually give the numbers at some point—which currently isn’t the case. So for now, I’m fine with it… xD poke | talk 12:31, 8 July 2014 (UTC)
Maybe we could split it into separate tables by rarity, and collapse them? Visual presentation can be changed at any time - that's the beauty of templates. :) I'll probably start working on this today, then.
The Iron/Soft version for all weapon types has around 150 variants, so that's already tested. I haven't looked at armor yet, but I'd guess it'll be about the same, since those 150 variants are already pretty dense in terms of level/rarity coverage. —Dr Ishmael User Dr ishmael Diablo the chicken.png 12:45, 8 July 2014 (UTC)
Thanks for the inspiration, poke! I modified the templates so that rarity is defined per-table instead of per-row, which shaves 10% off of PAGESIZE. Also added the "expandable" class to the tables, saving a ton on displayed page size. I think it looks pretty good this way. (Removed links to my earliest examples since they're now broken, we're not going to split pages like that anyway, and I don't feel like fixing them.) —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:34, 8 July 2014 (UTC)

(Reset indent) I must have forgotten to post the link to my proposal on User:Chieftain Alex/sandbox5. Similar except poke's collapsible tables. (not sortable I guess is the main disadvantage). -Chieftain AlexUser Chieftain Alex sig.png 19:08, 8 July 2014 (UTC)

Geh, you guys are making me redesign too much - I'm ready to start posting the data! But seriously, I like that. Sortability is mostly pointless, since I'm already sorting them by level, which is directly correlated with value and weapon strength/defense (the first data listed under "Stats", so it will determine sorting for that column). The only other thing one might want to sort by is prefix, so I guess that's a small loss. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:31, 8 July 2014 (UTC)
Yeah, I agree, sorting is not really that useful. Looking good though! poke | talk 13:47, 9 July 2014 (UTC)

(Reset indent) New topic: the regional loot weapons are the same as the tier 1 and 2 cultural weapons. Should we put all variants on the same page? Or should we keep the cultural version as-is and make a separate page for the loot variants? I'm definitely going to use separate pages for the crafted and loot versions of Iron/Soft weapons, but I think using the same page would be fine for these. —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:05, 9 July 2014 (UTC)

How many variants are there? I’d personally keep them separate if the amount of loot items gets too much to draw away the attention from the weapons you buy.
But looking at, e.g. Krytan Axe, it seems that the pages already list the loot ones, so adding them there would be fine I guess. poke | talk 11:45, 10 July 2014 (UTC)
There are between 30-40 variants per weapon type in the cultural/regional sets, so not that many compared to the generic set. And the table will be all nice and collapsed anyway. —Dr Ishmael User Dr ishmael Diablo the chicken.png 12:22, 10 July 2014 (UTC)
I've implemented a beta release on Iron Axe (loot) and Krytan Axe. This is the time for tweaks if anyone wants to make any. I'll give you until Monday.
Also created an {{otheruses loot}} message between Iron Axe and the loot page - it detects the presence of "(loot)" in the pagename to determine which message to show. Since we'll put the loot versions on the same page with the cultural weapons, it'll probably only be used on the Iron/Soft pages and thus can probably be subst'ed. —Dr Ishmael User Dr ishmael Diablo the chicken.png 14:12, 10 July 2014 (UTC)
That looks good to me, good job! poke | talk 14:19, 10 July 2014 (UTC)
Whee, it's Monday! Human-bot-mode, engage! —Dr Ishmael User Dr ishmael Diablo the chicken.png 14:01, 14 July 2014 (UTC)
Took three days, but all the loot weapons are finished. Now I have to figure out what all the skins are that drop for armor... —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:18, 16 July 2014 (UTC)

template:loot disambig

Is there a particular reason why we didn't create a template for the disambig bit at the top? -Chieftain AlexUser Chieftain Alex sig.png 18:58, 14 July 2014 (UTC)

I did make one, but because that note is only needed for 18 pairs of pages, I decided there was no reason to retain it as a template. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:20, 14 July 2014 (UTC)
We could still use the normal {{otheruses}} though: {{otheruses|variants that drop as [[loot]]|non-loot variant|Iron Axe}}. poke | talk 19:47, 14 July 2014 (UTC)
That felt like extraneous language, to me; the concise note I put on the loot pages seemed to be all that was needed. On the flip side, I liked the version I wrote with "lists the crafted variants" better than what the template would produce, "is about the crafted variants." And it's only 36 pages, so I didn't think it would cause any trouble. (guess I was wrong) —Dr Ishmael User Dr ishmael Diablo the chicken.png 20:05, 14 July 2014 (UTC)
whatever, I'd rather have the super lists without a loot disambig template than the disambig and no lists. Good work anyway. -Chieftain AlexUser Chieftain Alex sig.png 20:50, 14 July 2014 (UTC)

nearly finished

I think I'm finally finished with all the weapons and armor. Yeesh. So many stupid anomalies.

I've located the blocks of amulets and rings that drop as loot - there are 65 of each (split 22/22/21 in mw/rare/exotic). They're all simply named <prefix> [Amulet|Ring], so I guess I'll put them on Amulet (loot) and Ring (loot).

Fractal loot trinkets include accessories, and there are 12 of each - Cavalier's, Magi's, Rabid, and Soldier's in mw/rare/exotic. The amulets/rings will go on the above pages, but the accessories are Book of Rabid Deeds and the various Field Guides, e.g. Cavalier's Field Guide. It appears that the exotic versions of these accessories are the same as those sold by the [[Template:Temple vendor nav|temple vendors]]. —Dr Ishmael User Dr ishmael Diablo the chicken.png 22:01, 28 July 2014 (UTC)

I'm loving the high quality bulk editing going on. I'm sure that it is driving you stir crazy, but thank you for doing this. -Chieftain AlexUser Chieftain Alex sig.png 23:00, 28 July 2014 (UTC)
Dammit. Based on a few of the exotic trinkets pages (Book of Rabid Deeds, Cavalier's Field Guide, Magi's Ring, Soldier's Spineguard), it appears that at least some of them have a unique version (ID of 39xxx) different from the Fractals versions (ID of 37xxx). And, of course, these 39xxx versions aren't discovered in the API. Also of course, I'm at work and can't go look at the vendors in-game right now. So I'll have to halt editing of loot trinkets until I go home in 7 hours. Or maybe I'll take a long lunch. Or maybe someone who isn't at work will see this and help me out. —Dr Ishmael User Dr ishmael Diablo the chicken.png 15:17, 8 August 2014 (UTC)
39xxx versions are all from the temples. Cavalier's trinkets are: 39138 (accessory), 39143 (amulet), 39148 (back) 39153 (ring). Magi's is shifted one higher, Rabid two, Soldier's three, and the now unused Wayfarer's four. If that helps. Tyndel (talk) 15:58, 8 August 2014 (UTC)
Awesome, thanks! —Dr Ishmael User Dr ishmael Diablo the chicken.png 16:17, 8 August 2014 (UTC)
Would it be acceptable to merge all of the accessories into a single article for "Field Guide"? I don't know how much anyone would object to including the Book of Rabid Deeds in that page, since the name scheme is completely different, but apart from that it would make a lot of sense to document them all on one page. —Dr Ishmael User Dr ishmael Diablo the chicken.png 17:48, 8 August 2014 (UTC)

acquisition for random loot

Since I don't know of a better place to put this - many items in this game, including numerous exotics or other "unique" items, are obtained as random drops from pretty much any enemy or chest, and of course the Mystic Forge can give almost any item. But it looks like there's a lot of inconsistency for what to put in the Acquisition section of articles for these items.

Obviously, if it's one of the unique weapons that only comes from certain chests or champion loot bags, that's easy; same for if it only drops in particular regions. But for ones like Storm (a good example of superfluous acquisition information), we should have some boilerplate consistent text that says "this is a random drop, it can come from anywhere". Just in a more professional manner.

It might even merit an addition parameter in the item infobox, "random = y" or something. I dunno. Vili 点 User talk:Vili 07:54, 27 June 2014 (UTC)

I agree, we should think of some generic text for it. Unfortunately, the infobox won’t work because the infobox doesn’t have access to the acquisition section. poke | talk 12:02, 27 June 2014 (UTC)
That seems good enough to me. We generally haven't bothered to mention the MF since you can get pretty much anything in the game out of it. —Dr Ishmael User Dr ishmael Diablo the chicken.png 12:20, 27 June 2014 (UTC)
Do we know for certain that champ bags can give "generic" exotics in addition to the ones specific to that type of container? Otherwise that looks good to me. Vili 点 User talk:Vili 00:31, 28 June 2014 (UTC)
We might want to put that into a template so we have the same text everywhere. poke | talk 15:58, 28 June 2014 (UTC)
Personally I thought it was hilarious that you cited storm as an example, with uses {{Exotic weapon text}} followed by "we should have some boilerplate consistent text". -Chieftain AlexUser Chieftain Alex sig.png 16:09, 28 June 2014 (UTC)
There's no way to tell if text is a template without editing the page, which I didn't, because I wanted to bring the issue up here for input rather than arbitrarily go off on my own quest to standardize every generic exotic. Vili 点 User talk:Vili 22:27, 28 June 2014 (UTC)
well just edit it, if someone doesn't like it, they'll revert. The reason that I put that stuff in a template in the first place was so that people could change the wording. -Chieftain AlexUser Chieftain Alex sig.png 22:49, 28 June 2014 (UTC)

Look and feel

User Santax vector.png

So I've been playing around with my own vector.css to bring the look of the wiki closer to that of the official website, and it occurred to me to ask whether that is something the community would be interested in as a whole? I can't take all (or most, probably) of the credit; I don't remember who exactly I stole bits and pieces off but I remember Ee was one of them. Changes include:

  • Changing the logo to be more similar to the Living World logo
  • Use of Eason Pro for headers and Cronos Pro for content (not quite in line with the Graphic Design Guidelines from the Asset Kit because they don't suit web at all, but more like what is used for the website)
  • Use of Aspire font for h1 headers—we've been told that the font wouldn't be used again in official designs in the past, but actually it's been present on some recent Living World videos
  • Changes hr and underlines on headers to use the style on the forums and website rather than a solid line

It's not perfect—I've no background in design, and there are things like font sizes that definitely still need tweaking. But I think it does look more consistent with the website that the wiki currently does, and would be interested in seeing what people would think of moving toward something like it. –Santax (talk · contribs) 15:12, 12 July 2014 (UTC)

First of all, since Monobook is still the default skin, these changes are not really all that useful in total. Primarily, we should focus on improving the design for all visitors, not only for the small subset of users who decided to use Vector. That being said, overall, that looks feels a bit out of line in a number of places. For example as you already said, the font sizes are really inconsistently bad. Also, Aspire for headers seems like a very bad idea to me, since it’s not really well-legible and falls out of style from the rest of the wiki. It might be a good choice for artistic and stylistic places (on images, in videos) but to use it as the introduction to every article—the title—doesn’t seem that good.
As for the logo, I don’t like it. We’re an independent entity, and as much as I like having a style that’s similar to the official sites, I think keeping a distinctive logo is very important for us. And that Living World logo just blends away far too easily.
That being said, I’m definitely for improving our overall layout. And in fact, I have been thinking about and pre-planning something for quite a while now. Since you brought the topic up now, I guess it’s a good time for me to finally write about it. I’ll post something later. poke | talk 15:54, 12 July 2014 (UTC)
Good to hear :) Aspire and the logo were less "serious" suggestions I guess, but Arial as a font for the body of articles really is pretty inconsistent with the websites. The other thing was adding adding The Atlas to the header, but you've already commented on that. –Santax (talk · contribs) 18:01, 12 July 2014 (UTC)
You recall perhaps that you can add stuff to your own personal .js file e.g.
function addAtlas() {
   mw.util.addPortletLink ( 'upperBar', 'http://atlas.guildwars2.com/en/', 'The Atlas', 'n-gw2w-atlas', 'View the GW2 Atlas' );
}
addOnloadHook(addAtlas);
but seriously though, that font that you've used in the body text for articles is far harder to read. -Chieftain AlexUser Chieftain Alex sig.png 19:16, 12 July 2014 (UTC)
I do however quite like the tabs not having rounded corners. (also, Santax, you haven't ticked "Enable simplified search bar (Vector skin only)" in the search preferences.. looks so much better imo) -Chieftain AlexUser Chieftain Alex sig.png 19:34, 12 July 2014 (UTC)

Story achievement effects

I just completed the walkthroughs for the story achievements of Gates of Maguuma. The interesting thing about those achievements is that each comes with (at least) one achievement effect that stays on your character as long as you are still eligible for getting the achievement in a single playthrough. For example, skill #25018, “Achievement: Dashed Advantage” (), has the following description:

Eligible to receive credit for Dashed Advantage.
Hop, jump, and dash your way into a hidden place to attack unsuspecting foes during the final fight.

Obviously, we would want to document that somewhere (with skill id so we can search for the chat code). The question is: Where and how? Right now, the walkthrough for the achievements are on the story chapter articles (e.g. Fallen Hopes#Achievements) and I think it fits there pretty well (especially since you can reference part of the general walkthrough there without having to explain it again). The achievements are defined on the achievement category page, e.g. Gates of Maguuma (achievements).

Now, one possibility would be to create actual articles for each achievement, put the walkthrough there and also document the achievement effects there. For above reasons, the walkthrough fits better on the story article; and some achievement effects are also used for multiple achievements, so we couldn’t document them there either, making this all not really ideal. Another option would be to document the achievement effects separately as short articles; this would make it consistent for all skills/effects, but also put those skills a bit out of context, requiring the achievement walkthroughs to reference them in some way. One final option would be to put the documentation on the story article itself. Since it’s just a small effect, that does not have too many information about itself (apart from 2–4 short lines of description), it wouldn’t clutter too much and we could have it all centralized in one place.

What do you think how we should proceed? poke | talk 00:30, 14 July 2014 (UTC)

How are you picturing your last proposition? Would you have each effect under its related achievement or would you put them in all together? --Ventriloquist 00:41, 14 July 2014 (UTC)
Since there are shared effects for some achievements, putting them together in a single “block” would probably make more sense. Depending on the size of that “block” we could possibly float it to the side too. Guess we can try some different designs there. poke | talk 00:47, 14 July 2014 (UTC)
I see, I see. I find that approach the best; separating each effect would create too much of a gap between all of the effects and their achievements, which benefits no one. It's a bit late and I'm super-tired but can't sleep so I might be missing something, but would you still create a page for each effect? --Ventriloquist 00:57, 14 July 2014 (UTC)
No, in that case, I would just put the skill information as SMW subobjects on the story articles, so we wouldn’t need separate pages (which would be very boring anyway). poke | talk 01:22, 14 July 2014 (UTC)
Sounds good. I guess now we wait to see what the others'll say, but I think this is the best approach without creating redundancy. --Ventriloquist 01:26, 14 July 2014 (UTC)
Each effect needs a page since it's an effect. The {{achievement table row}} has walkthroughs defined either on the achievement category page or an individual page. The effect would be defined in the template and generated in the achievements templates like the other stuff. You can generate the achievement description and details with {{achievement|name=Dashed Advantage}}. I detailed how to map achievements to pages in here so the template can link to the specific section. I gave an example on Cornered. The default is doing walkthroughs of the achievements on the category page, but given that this achievement are spread across distinct instances, individual pages are suited well for these.--Relyk ~ talk < 01:41, 14 July 2014 (UTC)
No, story achievements are not spread across instances. That’s the point. Each instance, or more precisely story chapter, has a number of achievements. Each story chapter also gives you a number of effects (technically) that are required for getting those achievements. There is no clear mapping between those though; there are achievements that don’t have an effect, there are achievements that have one or more effects, and there are effects that belong to multiple achievements.
I am not interested in listing the achievements on the story article. I was always of the impression that those boxes are rather hideous and look out of place in articles (outside of achievement lists); and they definitely don’t fit that well on the story article. We might want to link to the achievement on the category list, but other than that, I don’t think we need or should put the achievement details there.
I also don’t believe that the walkthroughs for those achievements should be on the category page. For reasons explained above, separating the story walkthrough from the achievement walkthrough makes little sense and will only make things more complicated to understand. Usually, you would expect players to attempt getting all achievements in a single instance too, so having them all together makes a lot of sense.
I was primarily asking about how to document the achievement effects. Since they are pretty special, and only technically effects/skills, I don’t think we should create an article for each. Those articles would be rather useless; the infobox would always show the exact same information, only the description would change, and there likely would be a link to the story article. That’s all. Similarly how we don’t create articles for every single achievement, collecting the achievement effects in a more-central place would be a lot better. And having them on the story article itself would allow us to reference them easily in the walkthroughs. poke | talk 03:42, 14 July 2014 (UTC)
I agreed an instance has a set of achievement effects, so that doesn't seem to be an issue. If we want to use correct terms, these are episode achievements as Gates of Maguuma is an episode and story instance is the in-game term (simply instance).
The box doesn't have to be how we present it, but some details related to the achievement are desired, like the waypoint link, rewards and linking to the achievement page. I also agreed the instance page is the appropriate place and we can use the templates to do so if we want. This isn't any different from other achievements like those for bosses.
I don't see what's wrong with creating individual effect articles. It doesn't matter whether the pages are useful, we still need to document them. We can then access them like any other effect with templates. We already have this for Mistlock Instability and articles for individual effects.
We need to identify that there's an effect indicator for the achievement, but more than naming the effect isn't useful for the walkthrough. We can present the achievement information directly if needed.--Relyk ~ talk < 21:40, 14 July 2014 (UTC)
I would rather not create a new page for them not when a one or two blurb sentence of "This achievement is attainable when the XYZ effect is active. It's description is ABC" on the story page achievement section would do. As that is all the pages would really be. Anzenketh (talk) 15:07, 25 July 2014 (UTC)
We already have pages like that. The small size of the page is no reason not to create it. —Dr Ishmael User Dr ishmael Diablo the chicken.png 15:26, 25 July 2014 (UTC)
Ugh, don't remind me of those Challenging effects I did Ish, there were so many... Anyway, the rule I go by is, if it has a unique ID, it gets its own page. Many effects throughout the game contain little to no relevant information, ex. Bulk Stacking, however it does exist as a unique ID, it is linked to a specific thing and for that, deserves a page, if you ask me. --Ventriloquist 19:10, 25 July 2014 (UTC)

Story iconic characters -- Location, Dialogue

The iconic characters currently have old dialogue and old locations noted on them. I don't think they have a location outside of a instance. Their dialogue is also old and noted on the story instance page. How do we want to document that? I say we remove the location and archive the dialogue. Then link the Individual story instances that that iconic participates in on their page. Anzenketh (talk) 15:11, 25 July 2014 (UTC)

That's generally how we've been doing it. --Sialor (talk) 20:47, 25 July 2014 (UTC)

waypoints -- yes, I'm bringing this up yet again

Previous discussions about creating articles for waypoints have always fizzled out, with the main point of contention being that most of the articles will hardly have any content and thus aren't worth creating. Well, through no outside influence that I can detect, User:Louise has created tiny articles for nearly all the landmarks that have waypoints. Since no one has raised any objections over these articles (and it's been a few weeks since she started, on August 8), and since I know we have quite a few people that watch RC and surely would have noticed them, I must assume that people accept these articles as valid and don't have any problems with keeping them around, in spite of their lack of meaningful content.

Given that, I think we could give these pages more "validity" if we made them describe something with an in-game nameplate - the waypoint - rather than an ambiguously-defined landmark. And thus I am arguing yet again that we create articles for waypoints. —Dr Ishmael User Dr ishmael Diablo the chicken.png 12:22, 25 August 2014 (UTC)

Wouldn't that completely invalidate landmarks? If the waypoint pages would replace landmarks, both in information and function, wouldn't it feel...silly? For example, we have Concordia and Concordia Waypoint. The Concordia page should contain all the information about the fort, its role in the personal story, how it got destroyed etc. Now, if it was a waypoint page, most people would assume that the page would have something to do with the waypoint, no?
To me it seems like a pointless split, since the landmark pages work great because they record exactly that - a landmark, an important location in the game that isn't strictly defined but still holds historical and other values. Furthermore, if players were to type in "Kiel's Outpost", which they might have seen in an interaction with the NPCs, they'd be greeted by a redirect (I assume you'd move the current pages to their respective waypoints), which would guide them towards "Kiel's Outpost Waypoint"; and to me, that seems like an unnecessary complication. Sure, the waypoints are actually defined as a thing in the game, compared to landmarks, but they still aren't what the page would describe them as.
As for the actual names of the areas/landmarks, they usually aren't ambiguous since they're unique - in the sense that - they, like I said before, hold value, whether they mark a camp, fort, outpost or even a factory. It seems that these pages would be worded oddly, too; for example, we'd have "Kiel's Outpost Waypoint is a waypoint located in Kiel's Outpost. Kiel's Outpost is...". That seems like an unnecessary complication for little benefit. I appreciate validity, but just because it's not defined in the actual game doesn't necessarily mean it shouldn't be defined on the wiki. --Ventriloquist 12:53, 25 August 2014 (UTC)
Alright, I guess I'll just give up on ever getting waypoints documented properly. —Dr Ishmael User Dr ishmael Diablo the chicken.png 13:10, 31 August 2014 (UTC)

Documenting skins - in their own namespace

A few weeks ago, I started a preliminary discussion about how to properly document skins, with the idea of creating a new namespace specifically for them. The benefits of doing this are numerous, but the biggest one is that it completely eliminates the need for disambiguation qualifiers on page names, i.e. "Skin name (skin)". It also means that all links to skins in infoboxes (and other templates) can have the namespace applied automatically, which is what we already do for images.

There were a couple objections raised, namely, that using a namespace would force a disambiguation rule onto every single skin page, and that separating skins into their own namespace somehow implies that they aren't a part of the normal game content. I agree on the first point, although I see that as a benefit - rather than trying to remember whether a certain skin is at "Skin name" or "Skin name (skin)", you always know that it's at "Skin:Skin name". As for the second point, I disagree - I don't think putting something in a special namespace somehow means that we see it as "less important" than other content; on the contrary, I see it as implying that this content is extra-important, so much so that we don't want it to be confused or impacted by all the other content in the mainspace.

Thanks to the efforts of User:Sanna and User:Ventriloquist, we can already see the complications of the current system. Having to enter | skin = Skin name (skin) in every weapon's infobox feels extremely redundant. It would feel much more professional (and be much easier to type) if you could just enter | skin = Skin name and let the template add the "Skin:" namespace prefix.

At the preliminary discussion, I also list a few technical benefits to having skins in a namespace. The one most relevant to users would be the ability to restrict searches for skins to the "Skin:" namespace. We can also apply some custom CSS to the namespace, if we wanted (similar to the Feedback namespace on GWW). Lastly, SMW is more efficient when filtering by namespace than when filtering by a property value (cf. Template:Wardrobe). —Dr Ishmael User Dr ishmael Diablo the chicken.png 13:31, 31 August 2014 (UTC)

So basically we could copy the php settings from GWW for the new namespace, thus simplifying the setup a bit (obviously renamed to Skin + Skin_talk).
I still think that this is a good idea + it would massively speed up the documentation of the skin pages if we could roll it out in a new namespace without fear of collisions with existing pages (skin + weapon names are often shared, even if the skin is used on many different items). -Chieftain AlexUser Chieftain Alex sig.png 13:41, 31 August 2014 (UTC)
When editing the Seraph and Ebon Vanguard pages I thought that it would indeed be easier if we only needed to add the skin parameter on items that use skins from other sets. As a default we can then assume that the name of the weapon and its skin are equal, and display a link of the matching skin page exists. In any way I am very happy with the skin pages, because it shows which items share the same skin. I'm already manually tracking inexpensive versions of exotic weapons myself, having these skin pages helps a bit. If namespace is easier and better performing, then by all means lets go for it. ~ Sanna 13:43, 31 August 2014 (UTC)
To be honest, anything other than the current system of documenting skins would be much appreciated. It is a bother to slap the otheruses on every skin/weapon page, combined with the added skin parameter in the infobox. Skins are definitely an awesome system of tracking how many skins share their appearance, and with what; sadly, I don't think a lot of players will even notice the skin option to their right. We definitely need something better to both document and display the skins. As Ish said before, I'm sure a lot of players come to these pages looking for skins, only to leave the wiki empty-handed. With everything that was said, any system that would merge what we have now is awesome in my book wardrobe. --Ventriloquist 13:53, 31 August 2014 (UTC)
I'm with V above. I just realized that with skin pages, you can also manually list related skins. Like with Accursed Chains and Spirit Links for example. The skin addict in me is getting a little excited here! ~ Sanna 14:14, 31 August 2014 (UTC)
As I have previously stated, I doubt that this is really a good idea, and I certainly don’t see it solving the problems you mention here. You say that it eliminates the need for disambiguation qualifiers, but in fact, a namespace name is part of the article name, so you are explicitely adding the disambiguation qualifier to every skin, even those that are completely unique. Of course, from an organizational point of view, categorizing everything makes sense and putting that right into the article name is good, right? Well, I don’t think so. I seem to be saying this a lot, but a wiki is not a database. We don’t need full structure already within the article names. One of our biggest features as a wiki is that we don’t have a fixed format for stuff. We don’t require everything to follow some exact rules, we can decide on a case by case basis.
If we took that “categorize in the title” thing further, we could invent “Item” and “Skill” namespaces, or even go as far as doing “Ranger skill:Slice” and “Thief skill:Slice”, but that’s just ridiculous because there are only few actual collisions. Yes, many skills share the same name with an item that has that particular skill, possibly requiring a disambiguation there; but is that really the proper solution? Do we even need separate articles for skins and the item with the same name that has that skin? I’m actually not sure. Articles like Ascalonian Performer armor, and especially articles for individual pieces like Ascalonian Performer Mask, would be incredibly boring if we decided to split them up by skin and item. I’m sure we could instead come up with a way to document both the skin (maybe most prominently as it’s possibly of primary interest to people) and the original item that has that skin (which does not come with that many own unique properties anyway) on the same article.
Arguments like searching for skins will be easier as one can restrict the search to the skin namespace are pretty void: Someone searching for a skin either knows the name (or a substantial part of it—in which case, nobody will bother to go to Special:Search and select the skin namespace only; instead, they will just search for the name, expecting to find it anyway), or they are interesting in a whole list of skins (which oddly enough doesn’t exist here). And having a skin namespace does not mean we can get rid of {{otheruses}} either; if I want to see for example the “Researcher's Coat” skin, I search for it and get to the Researcher's Coat article. If that article then doesn’t give me the skin details, there at least needs to be a link to the skin page—and that shouldn’t be hidden somewhere inside the infobox.
The fact that you need to enter | skin = Skin name (skin) is a flaw of the infobox and the underlying SMW lookup. We already use Property:Has canonical name for everything, and simply looking up the canonical name “Skin name” from the skin category should be simple enough. One could even do a {{#ifexists: {{{skin}}} (Skin)|{{{skin}}} (Skin)|{{{skin}}}}} here if that’s really your argument for the namespace.
tl;dr, I don’t think a separate namespace is really the solution for the actual problems we are having with the skin documentation. poke | talk 18:07, 31 August 2014 (UTC)
Interesting point. If you put it like that, we could adjust the skin parameter to automatically suffix " (skin)" to a skin name, and to check whether the page "{{PAGENAME}} (skin)" exists. This would both eliminate the need to add (skin) behind everything AND would automatically cover all cases where skin and item name are the same. Of course, we would have to agree on the course taken when a given skin page does not exist (will we categorize that page, or allow for red links, etc.).
The otheruses template could also be auto-added above the infobox through the infobox template. I do stick to my conviction that we should document skin pages, as I think they are quite handy. The skin infobox can also add proper categories, so we actually will get a proper list of unique skins available (as you mentioned we don't have now). Having a unified way to list these skins also works great with items that come solely in transmutation form, like the skins bought from the Black Lion Weapons Specialist.
I personally don't mind that the link to the skin is in the infobox, it is a nice place for that kind of static information if you ask me. ~ Sanna 18:21, 31 August 2014 (UTC)
Yeah, I am not against listing the skin in the item infobox, I was just saying that as a means for disambiguation, it wouldn’t be enough, so adding a {{otheruses}} would still be necessary (although, as you say, it could be automated, like {{Historical content}} is automatically added when setting historical = y). poke | talk 18:28, 31 August 2014 (UTC)
"you are explicitely adding the disambiguation qualifier to every skin" Which is exactly why I think this is a good idea: when you have a 90%+ collision rate, it makes a lot of sense to systematize the disambiguation. —Dr Ishmael User Dr ishmael Diablo the chicken.png 20:48, 31 August 2014 (UTC)
I'm in agreement with poke. The namespace doesn't solve the disambiguation because we still have to provide links between the item and the skin. Players won't find typing in " (skin)" after the item any harder than "Skin:" and is consistent with the rest of the wiki. Rather we should expect players to navigate to the skin page through either the item page that gives the skin or use that chat link directly from the game. The skin will be linked in the item infobox and the nav for items sharing the skin.
I don't share sentiment others in the discussion have that this is of great importance compared to other content. I agree that individual pages are required for the purpose of navigating to items with the skin and item galleries, but acquiring the skin always means the player has to navigate to an item page first. This is true for almost every single page because of the high collision rate.
For another proposal, we can use the icon file page for hosting the skin since the skin names are unique. The format will always be "File:<skin name>.png". The png suffix isn't a huge deal since the search function will filter out results. We can host all the skin properties and image gallery on the file page. That provides the same advantages your argument for a skin namespace provides. Poke argued that this "buries" the content from the reader and this isn't the primary use for the file namespace. I don't see this being an issue since then skin pages end up getting buried with normal disambiguation in the first place. Our primary use of the skin pages will be for generating the {{Wardrobe}} and the galleries, so using the file namespace provides direct benefits in this regard and in a sense the skin is simply a file of animated model. If we use the weapon appearance file for hosting the skin page, the skin gallery queries don't require defining the imageproperty and captionproperty parameters.--Relyk ~ talk < 16:53, 2 September 2014 (UTC)
“Poke argued that this "buries" the content from the reader and this isn't the primary use for the file namespace.” – Did I? I don’t remember that… I think? poke | talk 17:22, 2 September 2014 (UTC)
(Edit conflict) I'm going to be honest with you all. Apart from ishmael, I can't really see any of you ever putting the effort in to document all of the skins. (I can't check the skins ingame, which would massively hamper my own ability to do this.)
The file namespace idea has already been sounded out (on some property talk page somewhere, I'll see if I can find it), but its not a good idea - the file pages have a formatting that would prevent the skin appearing above the image, the metadata + whatlinkshere aren't too pretty to present either. Files are haphazard on the wiki and are not entirely sensibly named. (When you start finding items with shared skins, you see many have different filenames chosen with no clear pattern as to which image to use.) There will be a manual element to creating skin pages b/c of the crap file scheme.
The only tangible issue I see with a skin namespace is players finding it via Special:Search (same issue with the file namespace tbh). We could add the Skin namespace to the default namespace to search list to fix that, or just let users choose from the dropdown menu.
tl;dr version: I definitely think they should be documented. There should be a proper article on them. I don't like qualifiers. -Chieftain AlexUser Chieftain Alex sig.png 17:32, 2 September 2014 (UTC)
(Edit conflict) We could, in theory, use the skin pages to list all matching icons and skin images. Those could then be used as a direct source or fallback in the weapon and armor infoboxes. So you list only the skin (if the skin cannot be detected automatically) in the infobox, Semantic Mediawiki gets the rest. Sure it will be a lot of work, but if we optimize the current way of listing skins, it won't be too bad I think (judging from Vent and I's little skin adventure the other day). (I understand it may be a bit too much work to get it implemented correctly before all the skins are documented.) ~ Sanna 07:02, 3 September 2014 (UTC)
Yes, that has been the goal all along, but I've been putting off the skin documentation because I didn't want to deal with the 90% collisions and thought that a namespace was a good way to avoid that. I just really hate the idea of having 2,000+ pages with "(skin)" in the name, especially when a small proportion of them won't have that, which in my mind is a glaring inconsistency. —Dr Ishmael User Dr ishmael Diablo the chicken.png 12:02, 3 September 2014 (UTC)
"Apart from ishmael, I can't really see any of you ever putting the effort in to document all of the skins." You realize you are replying to my comment? I don't see why that would matter in any possible discussion? I don't expect people to navigate to skin pages since they don't hold useful information besides the image gallery. Do you mean the skin infobox appearing above the image? Because we don't need to use an infobox format on skins. I already responded on file naming, we use the skin name for the file and that gets shared between items. Not sure what you mean by manual element, I expect it to be manual since it's a wiki.--Relyk ~ talk < 13:42, 3 September 2014 (UTC)
The reply to your comment was a subtle hint that you like to suggest projects of epic proportions and then let someone else do them.
RE content other than gallery appearance: icon, chat link, name (may not match filename), and (most importantly?) weapons using the same skin. -Chieftain AlexUser Chieftain Alex sig.png 17:32, 3 September 2014 (UTC)
I'm pretty sure we can get people into working this out. I'd certainly help out with editing the individual pages. This is not something we can do all at once, but clearly simply doing nothing is not going to satisfy everyone. It could even be a project like Project Cartography (I'm not sure if there's already an existing project for equipment). Plus, with smart templates we can automatically load most skin data using {{PAGENAME}} and only manually point equipment with different names to their skin. The entire wiki is a load of work of epic proportions, so the more we can automate, the better. As for the slight annoyance between you guys (Alex, Relyk), that's another matter that should not necessary impact the decision of this matter, if you ask me. ~ Sanna 18:37, 3 September 2014 (UTC)
I can generate the entire collection of skin pages automatically, that's not the issue. The issue to me is the page naming scheme without using a namespace, which, IMHO, sucks. I can't automate the creation of all the skin pages if they're not all consistent. And no, Relyk, we should not co-opt the File namespace for this, because that namespace already has a special function. —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:42, 3 September 2014 (UTC)
I'm thinking what the role of a namespace is. We have namespaces for administrative subjects which make the wiki function properly, like users, templates, wiki info and settings. So far, using a special namespace for anything other than that (e.g., everything that is about the subject of the wiki, as opposed to the functioning of the wiki), is unusual. As such I can totally understand that creating a namespace for skins is seen as illogical or making a big exception for one aspect of the game. In true wiki fashion, suffixing (variant name) to the title of an article is pretty much standard on wikis and does sound like a good solution. I however don't know enough about wiki mechanics to compare suffix and namespaces with each other. As a personal preference, I vote for suffixes. But if there's a significant benefit to using namespaces, like Ishmael mentioned, I am just as willing to accept that. ~ Sanna 19:07, 3 September 2014 (UTC)
No one is arguing that it's an illogical approach. I'm concerned that we have other ways to document skins that are less confusing and more intuitive than what creating a new namespace would do. Readers likely won't notice the namespace because they will access the page through either: using the /wiki function, which will map the chat link to the page, or from the weapons that use the skin. It's less effort for users to navigate to the item page sharing the skin name first and navigate through the link than to know to prefix with the skin namespace. One concern is that this makes it harder for new users to create skin pages. They will create a skin page with a qualifier and create wikilinks and then someone will have to move the page. Automation isn't really a solution since this is a wiki, but I do agree it's appropriate for this task as the skin pages are data and won't need many changes after they are created.
Are there reasons we can't store all the skins in subobjects? That's solution we did for achievements and skins have a similar or less amount of content and the collision rate argument along with already storing skin information. If we split pages by equipment type, players can easily navigate between the skins they want on whatever peice of equipment and provide navigation to equipment sharing the skin. The few skins that do have unique pages will redirect to the appropriate section. The chat link search can provide a link to the subobject and users don't have to worry about disambiguation.--Relyk ~ talk < 20:37, 6 September 2014 (UTC)
"access the page through either: using the /wiki function, which will map the chat link to the page, or from the weapons that use the skin" Then it shouldn't matter what namespace the skin page is in, since (according to both you and Poke) readers aren't going to be navigating directly to skin pages in any case.
"this makes it harder for new users to create skin pages" I don't foresee "new" or inexperienced editors ever needing to create skin pages, because there should always be someone like me or Tyndel or W.Wolf around who can do so directly when the skin appears in the API (which happens immediately after a release, since skins appear in the wardrobe and don't have to be "discovered" like items).
We are already storing skin data in subobjects - but you can't provide a list of items that use the skin from a subobject, that's why we're having this discussion to decide where to create pages to do that. —Dr Ishmael User Dr ishmael Diablo the chicken.png 21:49, 6 September 2014 (UTC)
(Edit conflict) We already do store the data in subobjects - just not the icon and not the image/appearance data. We don't have the mapping between the skin and armor/weapon/back item bit setup yet - this needs adding to the armor/back item/weapon infobox at the same time. Sticking it on a page rather than as a subobject means we can query for items with that skin + present the appearance data to the user. Subobjects mean we could store it all in a boiler room somewhere (like we do at the moment), but we can't fit many high information density subobjects on a single page (breaks subobjects ><) + subobjects (although beautiful to us) aren't very accessible to the general user. -Chieftain AlexUser Chieftain Alex sig.png 21:51, 6 September 2014 (UTC)
@ishmael, you don't need to? You simply query items for Property:Has skin, like {{skin list}} does, where the property map the value to the subobject page internally. If only experienced players will be adding skins, the difference between a namespace method and subobject seems superficial.
@alex, we have to store the icon and appearance in the subobject. Using subobjects does not stop us from querying items for the appearance of their skin. Separating pages by type doesn't get close to that subobject limit, where the average 123 skins per type isn't close to the 1777 limit. Like ishmael pointed out, experienced users are more likely to add skins. The skin prefix is actually less accessible since users interface with subobjects using templates and aren't even aware of their presence.
I have a mock up on User:Relyk/skin/Axe using our subobject data giving examples for my responses. It's not inconceivable to use a gallery format for these pages either to act as an expanded form of the wardrobe. A row-based list has the image preview, so a large list of items sharing a skin has an advantage there. We will already generate these skin galleries and the only way to include the extra information with the semantic gallery format is to store it all in a caption if we wanted that.--Relyk ~ talk < 23:59, 6 September 2014 (UTC)
While your mockup works, it's far from optimal. For one thing, you're querying ?Has appearance from item pages, when that should be a property of the skin and the items should be the ones doing the querying. Same goes for icons, which you haven't included.
The biggest problem, however, is that the page is HUGE. Sure, you can use browser search to find what you're looking for on the page, but I know too many people IRL who have no clue that browsers even have a search feature. Also there's no way to compare skins - with individual pages, you can open them in separate browser tabs and switch back and forth between them (the people who don't know about search do know how to use tabs - even if they do use "Open link in new tab" from the right-click menu instead of Ctrl+Click - because they're a much more obvious feature). —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:43, 7 September 2014 (UTC)
Skins don't store their appearance or icon yet, hence the mockup. The process I imagine people using for looking up skins goes like this: People will compare skins using the item pages since the pages will display the appearance of the skin and other items sharing the skin. If the item and skin collide, the player will find the item page they want and stop there. If they navigate directly to the skin by a chat link, they can open the image in a new tab or one of the related items in a new tab, then navigate the gallery for other skins and open tabs for items/images they want to compare.
For namespace, if the person looks up the item for its skin, they will stop at the item page since they don't need any additional information about the skin. If they look it up through chat link, they then have to look up the other skins by chat link or have the additional step of navigating to the gallery for comparison. This ends up being more intensive on the user. Even if players can use the namespace shortcut to a skin, they won't have an advantage over starting from the item pages for the comparison step.
In the case of no collision, a redirect is required and either method leads to the skin information. Navigation is almost guaranteed to go through the item pages because of the collision rate. Individual articles are necessary for additional information beyond what we would display on item pages or a table, but I can't think of any cases? The namespace method has a a slight advantage in a wardrobe presentation where we only supply icons and tooltips, but linking to the first item using a skin gives the same result as far as the reader is concerned.--Relyk ~ talk < 01:38, 7 September 2014 (UTC)


Speaking as an average joe user who doesn't understand things like property maps or subobjects at all - what the consumer wants is 1) a gallery of skins for each type of (visible) equipment, like what the in-game wardrobe has; 2) information on duplicate items that share a given skin; and 3) up-to-date acquisition information (e.g. "mad memories was only obtainable during a past halloween event"). I do not think it matters to the consumer one way or another whether they end up on an "item page" or a "skin page" as long as the info is there (either via searchbox/in-game command or via visual gallery browsing).
One thing to keep in mind, though, is that most people get linked actual items rather than "skins". Linking a skin from the wardrobe is only possible if someone's actually standing at the bank (or knows the chat code offhand); typically, when out adventuring and people ask "Hey, what is that cool axe you're using?", players just link the actual piece of equipment.
Anyway, I'll let you guys get on with the technical discussion which I have no understanding of...whatever system achieves these results in an efficient, effective, and low maintenance way is what we should use. It's usually just the same few people who create/update skin pages on the wiki, so I wouldn't worry about how confusing xyz is for a new user to understand. Vili 点 User talk:Vili 04:13, 7 September 2014 (UTC)
I think one thing is abundantly clear by now - Vili, Relyk, and Poke have all said it one time or another. It won't matter to the average reader where the skin page is located, whether that be mainspace or a special namespace. They'll be navigating to it through the item page 90% of the time.
Thus, it seems like we should be making this decision from the perspective of the veteran editor. As a veteran editor myself, my most important concern is: which option will be easier to maintain? The option where skin pages are competing with item pages for pagenames and we have a mixture of qualified and non-qualified skin pagenames, or the option where all skin pages are named equivalently? —Dr Ishmael User Dr ishmael Diablo the chicken.png 05:09, 7 September 2014 (UTC)
I'd like to add two arguments (one pro, one con) to the suffix "(skin)" now that I've read your replies.
Pro: I tend to use the search bar with autocomplete a lot here on the wiki. If I were looking for "Vera" for example, then autocomplete would show me both Vera and Vera (skin), because they share the first part of their name.
Con: If you are using Property:Has skin like Relyk suggested, you always need to suffix "(skin)" to your query, for otherwise the search will give you no result. Not only is this extra effort, there's a high chance people won't realize they need to add this suffix. Even experienced editors would have to know that said suffix exists, which they likely do (only?) after inspecting the skin parameter in an infobox.
I also agree with Relyk that these skin pages will likely not have many changes and as such, once they are created they likely require little maintenance. As such I wonder if we shouldn't rather focus on user experience and not editing experience on this one (considering most code of these pages are copy/paste anyway). The only hard part is finding the right ID and what-not in the API. I don't know how this works, but if someone is willing to explain it to me later, I'll surely help out making more skin pages.
Also, since not everyone is familiar with the API: I wonder if our editor pool is limited to those who are already part of this discussion, which possibly changes the way we could approach all upcoming edits. These pages require a bit of effort to start with and may scare off new editors anyway.
~ Sanna 08:21, 7 September 2014 (UTC)
@ishmael, I don't buy the argument about there being a dilemma with pagenames being required at all, qualified or not qualified. We already use the table paradigm with coding achievements. The difference with skins is they have a high collision rate on the pagename, there are still 127 items on each page, and don't require individual articles to document. This is similar to how Bulbapedia presents items in a table instead of individual pages, although I'm not particularly fond of how they implemented it. A 127-ish items is a large page and navigating it might be too tedious and cumbersome for what it's worth (Not including an image of the item would help greatly and refer players to the gallery of the skins?). My argument is that players want to navigate to a list of skins of a given category whenever they are looking at skins as they want to compare them. This is a strength of storing skins with this method, we save the general user a step. With the namespace method, people will likely have to navigate to the skin page through the item page, and then navigate to a gallery or list of skins of the same type to compare. Coding around that isn't difficult.
@Sanna, discussion is more about alternatives to using the qualifier for disambiguation. Because the collision rate is so high, there will be confusion on when people want the weapon or skin information. The game differentiates them by color, but we can't do that and it still ends up being confusing. Disambiguation pages for every item/skin combination isn't a good approach. Bulbapedia uses disambiguation/qualifier method as a solution and it's unintuitive and time-consuming for both editors and readers. If we design the wiki so people navigate through the item pages to reduce confusion, we have some options on how we store the skin information.
The suffix doesn't matter in queries, you simply query an item for the property value and use that value in the query. We can do this with {{#ask:[[Has skin::{{#show:{{PAGENAME}}|?Has skin|link=none}}]]}} or similar.--Relyk ~ talk < 00:10, 8 September 2014 (UTC)
Bulbapedia is easily the worst wiki ever made, ever. Please don't use anything they have as a template for doing anything here. If they're doing it, it's almost justification to AVOID doing it here. Even just using it as an idea is probably bad news. And yes, that is just one of the many examples of that wiki's ineptitude; instead of each item having its own page where useful notes, bugs or trivia can be added, it's all smushed onto one page with massive lists that auto-hide so even linking to specific sections often ends up pointing at the wrong area of the page. That entire wiki is a huge disaster area. Let's not do anything they're doing, please :( -Auron 03:36, 8 September 2014 (UTC)
I mean, if you want to completely derail the discussion by complaining about Bulbapedia while ignoring my entire post Auron, those are all reasons encompassed when I said I'm not fond of Bulbapedia. I never even suggested we follow how Bulbapedia did it. But screw it, let's take this moment to detract everything else I mentioned to bitch about how bad Bulbapedia is because I happened to mention it, just to drag on an already tedious thread.--Relyk ~ talk < 04:05, 8 September 2014 (UTC)
TIL 1 post derails a thread consisting of dozens of posts, making every contributor immediately unable to continue discussing what they were discussing before that 1 post was made -Auron 05:42, 8 September 2014 (UTC)

Imo, stick them in a Skin namespace, and if we find massive problems with users not locating the information, then move it later to "_(skin)". Provided that we use templates to link to these articles, we shouldn't have problems with having to correct links in the future. We're being far too slow with this issue, folk are slowly trying to contribute skin info. -Chieftain AlexUser Chieftain Alex sig.png 06:47, 8 September 2014 (UTC)

That's what I was thinking, Alex, but didn't want to say it since this is essentially my proposal. Even if we end up not using the namespace, it's not going to hurt anything to have it defined. Heck, we already have an unused namespace: ArenaNet: so like Alex said, we can always move the pages later. —Dr Ishmael User Dr ishmael Diablo the chicken.png 12:13, 8 September 2014 (UTC)
There are, according to my outdated excel file, 131 skins with the same name but different weights - what will we do for these articles? If we had the Skin namespace, then it could be Skin:Black Earth Aquabreather (heavy), and if it were suffix, Black Earth Aquabreather (heavy skin). Or we could do some kind of {{item variant table row}} thing just for skins. -Chieftain AlexUser Chieftain Alex sig.png 17:29, 8 September 2014 (UTC)
If we end up with a skin namespace, then we’re not doing also subobjects. We can then use the whole namespace to mess around with page titles. That being said, I’m not happy with “Skin:Black Earth Aquabreather (heavy)”…
Just to make this clear: All a skin will store will be name, icon, gallery images, and indirectly items that use the skin (reverse-linked), right? That hardly justifies a separate article for each skin, let alone a namespace :/
I could easily imagine this being part of the weapon/armor infobox instead… poke | talk 12:04, 10 September 2014 (UTC)
Part of the weapon/armor infoboxes? They're supposed to be the ones that query this data! And just how would that work anyway? You need a single location that stores the data for a specific skin, not 20 different karma items that all use the same skin. —Dr Ishmael User Dr ishmael Diablo the chicken.png 12:31, 10 September 2014 (UTC)
To get back to Alex: there is a little quirk in the situation you mention: sometimes skins are equal but have different names. Let's take Jeweled Trident and Delusion as an example. Their skins do not share the same name if you look them up in-game, I am thinking that is because they are not of the same weapon type and to avoid confusion about that. In these cases I would give each skin their own page and add a note to each of them referring to the other skin. ~ Sanna 15:19, 10 September 2014 (UTC)
And to get back to the rest of the discussion: we are really taking a lot of time for this. Let's go by the wise words of Ventari: "Act with wisdom, but act." and give ourselves a deadline to make this decision. We could even tally between namespace and suffix. Have a decision ready by the end of the week, for example? ~ Sanna 15:19, 10 September 2014 (UTC)

Game updates and skill/trait changes

We can display the current skill description somewhere along with the skill change. Maybe display it in a tooltip of the change or under the description of the new skill. People liked this last time I did a skill comparison on a reddit comment. Maybe even display a before, after, and current skill tooltip to provide context to the update. This would be something similar to the skill history and we can do it more easily then what dulfy can do on her site or reddit posts. Game updates are one of the wiki's strengths because we can take advantage of wikilinks and additional formatting.--Relyk ~ talk < 19:31, 6 September 2014 (UTC)

Trading post prices

Eternity, Zap, Potato. Notice anything? poke | talk 03:19, 9 September 2014 (UTC)

I see that potatoes currently go for 2 silver, 4 potato. That's neat, especially since it barely impacts the page load times. Vili 点 User talk:Vili 05:19, 9 September 2014 (UTC)
Great new info. Don't have to go to gw2tp unless I actually want more details than that. :P Tyndel (talk) 05:30, 9 September 2014 (UTC)
yea it begs the question of if every item page needs a link to gw2tp/spidy -User Zesbeer sig.png Zesbeer 05:42, 9 September 2014 (UTC)
Still need the links for graphs and the addition stuff spidey does with cost calculations.--Relyk ~ talk < 05:47, 9 September 2014 (UTC)
(Edit conflict) Second, shouldn't we have WTB & WTS prices? Those can be wildly different. JSmith says default is that sellers will match lowest WTS and buyers highest WTB. Third, I agree with Zesbeer that the question is begged, but I think the answer might be yes, they do need links to spidy, since that site also calculates the cost of crafting items (although not forging them). I'm sure someone can figure out how to do that for the wiki, too (combining recipe data with the TP widget), after which...what Relyk said: graphs and stuff.
Regardless, this is great. Thanks for putting it together. – Tennessee Ernie Ford (TEF) 05:51, 9 September 2014 (UTC)
The mouseover shows the current highest buy order, default shown is the lowest available for sale. -Auron 06:09, 9 September 2014 (UTC)
I certainly have some more plans with the API; what won’t work are graphs though. We cannot store listing data, so we cannot make a graph on how prices changed. poke | talk 11:55, 9 September 2014 (UTC)
I missed the mouse-over data; pretty slick :) However, I still think "printing" only the lowest sell offer is misleading. We have a field for "cost" (how much to purchase from a vendor) and one for "value" (how much received from selling to vendor). Why don't we relabel those as "vendor cost" and "vendor value" and also have "TP Buy" and "TP Sell" and then use the tooltip to explain them? – Tennessee Ernie Ford (TEF) 15:05, 9 September 2014 (UTC)
Because the cost parameter needs to be removed.--Relyk ~ talk < 15:16, 9 September 2014 (UTC)

(Reset indent) I was so sure this was working earlier, is it appearing broken for anyone else, or is it just me as usual? >.> -Chieftain AlexUser Chieftain Alex sig.png 18:53, 9 September 2014 (UTC)

Silly Alex, server's down for 15 minutes. Tyndel (talk) 18:58, 9 September 2014 (UTC)
The API is up, but not configured correctly: XMLHttpRequest cannot load http://api.guildwars2.com/v2/commerce/listings?wiki=1&ids=xy. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://wiki.guildwars2.com' is therefore not allowed access. --Tera (talk) 18:59, 9 September 2014 (UTC)

Changing | Changed in Next | Most Recent Patch

I'd like to propose including a page-top template (and perhaps one for sections) that is designed to highlight important impending changes and similarly will serve to highlight those same changes after a patch. The primary text will continue to be in the preview notes; this is only meant to make it easier for people to see ahead of time that there's something worth reading in the patch and to help those who don't bother with patch notes realize something just changed. I also hope that it will discourage the all-too common practice of people rewriting bits of articles before the patch is live.

Example — Influence
Guild Influence [will become] global [after] the September 2014 Feature Pack. All localized upgrades [will be]] merged, including storage.
(the text in single brackets would change from future to past tense, based on a patch = live parameter in the template)
Guild Influence [has become] global [as part of] the September 2014 Feature Pack. All localized upgrades [have been] merged, including storage.

This wouldn't change the need to update articles at all. The purpose of the template is to make it easier for people to see what is about to change and what has just recently changed. It should/could be removed whenever the article gets updated again. – Tennessee Ernie Ford (TEF) 15:19, 9 September 2014 (UTC)

Add a note section to {{future content}}--Relyk ~ talk < 15:53, 9 September 2014 (UTC)

Help/intro pages, particularly "Welcome to the wiki" + "Guild Wars 2 Wiki:How to help"

Alright, you may have seen that I've tidied up some of the Help pages - particularly Help:Contents.

I'm now looking at Guild Wars 2 Wiki:How to help + Guild Wars 2 Wiki:Welcome to the wiki. I think that "Welcome to the wiki" is massively redundant with the other, but I also think that "How to help" is a pretty weak page title.

I'd like to propose:

  1. Deletion of Guild Wars 2 Wiki:Welcome to the wiki.
  2. Move Guild Wars 2 Wiki:How to help to "Guild Wars 2 Wiki:Welcome" (open to new title suggestions).
  3. Reorder the sidebar such that the first link beneath support is "Welcome" followed by "Help center" and then "FAQ"

I'd have been happy to do #1 without a CP post, but I'm a bit wary of editing the sidebar sequence unannounced.

Addendum: does anyone remember which page you get directed to after creating an account? (Suspect its a Mediawiki page) -Chieftain AlexUser Chieftain Alex sig.png 22:44, 5 October 2014 (UTC)

Directing people to a "How to help" page when they ask how to help is a strong title. "Welcome" doesn't say anything about the contents. Agree that the current contents of the welcome page is hardly useful for users.--Relyk ~ talk < 23:17, 5 October 2014 (UTC)
Hmm. FAQ looks pretty bad when not at the top b/c its only 3 characters long. Style vs substance. Could remove the FAQ link entirely. -Chieftain AlexUser Chieftain Alex sig.png 19:24, 6 October 2014 (UTC)
Wow, lot’s of good changes, thanks Alex! As for FAQ, I agree, it’s not really that useful in the sidebar. The FAQ is accessible from the help center, so I would put that at the top, “How to help” below, and remove FAQ completely from the sidebar.
I also think that “How to help” is a better title than a generic “Welcome”. And no, there [[:MediaWiki:Welcomecreation-msg|doesn’t seem]] to be a link on account creation. poke | talk 12:30, 7 October 2014 (UTC)
Thanks - I couldn't for the life of me remember what the MW page was called.
Sidebar suggestion also sounds good. "How to help" reflects the content of that article so fair enough, but I'll be the first to admit that I'd never visited it before yesterday. -Chieftain AlexUser Chieftain Alex sig.png 17:36, 7 October 2014 (UTC)

Presentation of Collections

Recently, a registered editor changed Brewmaster and at least one other article, stating that the previous presentation was too messy to identify the required items. They chose to follow the format used by many collection articles, using a simple list. I agree with user:Idris that the former style was useless for determining the required components.

However, I also think there's a place for a list of sources/locations, separate from the simple "what's in the collection" list. In particular, most of the items needed for Brewmaster can be acquired in two or more ways. I don't like the idea that readers might need to visit over a dozen articles to determine where to go. I'd like to propose that we do both for most collection articles:

  • Include a simple list of the required items, ideally automated via query.
  • Include an at-a-glance view of the items and sources, including vendor locations, nearest linkable landmark (PoI/WP), and interesting requirements (minimum level, etc).

Alternatively, we could create guides for the collections that go into such details and perhaps include maps for the harder-to-reach sources. For example, "Brewmaster/Acquisition guide" or "Guide to completing the Brewmaster collection".

I don't have a particular preference for the format, other than it should make it easier on the reader to locate the items on the list. – Tennessee Ernie Ford (TEF) 09:44, 3 December 2014 (UTC)

“including vendor locations, nearest linkable landmark (PoI/WP), and interesting requirements” – If you want that much information about each item, then I’d support the separate article idea. Having that many, actually unrelated, details on the collection article seems a bit extensive. Those articles should focus on just documenting it.
That being said, I do like the display on Uncanny Canner, which shows basic information about the acquisition, including multiple vendors. poke | talk 15:06, 3 December 2014 (UTC)

Article intro texts

In the past, at least to my knowledge (also from GWW), we always have used some sort of intro text in front following after the infobox, before further sections like acquisition and stuff. Of course, sometimes having such texts does not really give that much of a benefit from its content, as it usually means repetition from either the item description or the acquisition information. Yet, I personally still think we should keep them. They make the articles feel a lot less mechanic and may give some small details that would otherwise be lost. Now, I don’t really care much if people creating new articles for items add them or not; especially with the amount of items we get in an update, it could be tedious to write something about every item. However, what I don’t like at all is edits removing those. So I’d appreciate if we could agree to keep them. poke | talk 17:02, 3 December 2014 (UTC)

My general rule, like you said, is, if there's a description that explains the item's function, then there's no need for an introduction. Articles without any description, such as Bottle of Rum (trophy) could benefit from that because your general reader won't know what the item does or if it holds any special functionality. I just see it as repetition, but I don't hold some special opinion or anything - whatever you agree on is fine with me, I just thought that it looks better, but if I'm (possibly) wrong, feel free to revert anything I removed! --Ventriloquist 17:15, 3 December 2014 (UTC)

Wiki Wintersday Skin

Hey everyone, we made a Wiki Wintersday Skin on the French wiki that we are going to release later today. I would like to share with you a preview of it the and discuss if some of you would be interested to implement it on the English wiki. Stéphane will also share with you a package of the final pictures later today. You can find the preview screenshot here. We actually have five headers and one is randomly loaded. The logo is highlighted when passing the mouse over it. The gallery of headers can be found there. I can't detail all the skin here but you can certainly send me an email or make an account on the French wiki and I will apply the actual non finished skin to your css/js. Thanks, --IruleManik (talk) 18:26, 19 December 2014 (UTC)

Hello, nice job! I've had a brief look at your css/js, and I'm now wondering whether you have any of the header files without the french wiki logo added to them that we might be able to use? (You may see the issue here, as funny as hovering over the french header to reveal a different wiki logo would be, that isn't quite perfect :D) -Chieftain AlexUser Chieftain Alex sig.png 19:49, 19 December 2014 (UTC)
I'm off for two weeks, so perhaps another admin would like to consider implementing a wintersday theme? I was thinking of borrowing the snowflakes from the french wiki header + adding it to something like that. -Chieftain AlexUser Chieftain Alex sig.png 22:26, 19 December 2014 (UTC)
Done! And congratulations again Irule, that is amazing work, thank you for offering it to us :) poke | talk 04:25, 20 December 2014 (UTC)
Thank you Alex and poke for your answers. I'm sorry I couldn't share the pictures and reply before. I really like your skin Alex, good job! I'm super glad to see our footer on your wiki. It was offered with pleasure :)! Merry Wintersday! --IruleManik (talk) 10:02, 20 December 2014 (UTC)
Retrieved from "https://wiki.guildwars2.com/index.php?title=Guild_Wars_2_Wiki_talk:Community_portal/Archive_10&oldid=2197051"