GuildWiki talk:Style and formatting/Skills

From GuildWiki

[edit] Acquisition

I put the cantha and tyria subs for future consideration but it takes up too much space and i'm sure we can do that just as easily in future chapters. Number two is easier to read imo — Skuld 03:36, 12 July 2006 (CDT)

I think continent is not important, but campaign is. How about:

Sigh... in general I hate putting bullet points inside tables, the wikicode is just ugly, yet here I am... -PanSola, LAFTable(sing) 06:08, 12 July 2006 (CDT)

How does not using bullet points inside tables make wikicode look ugly? Without them, the generally structure of the whole thing ain't really that much different right? Using tables always makes things look complex. --Ab.Er.Rant @ User:Aberrant80 (msg) 06:19, 12 July 2006 (CDT)

I meant using bullet points inside tables make the wikicode look ugly (or messy). This is because the bullet point has to start as the first character of a new line. -PanSola, LAFTable(sing) 03:24, 14 July 2006 (CDT)

I personally don't think tables look good for this at all, especially seeing as the wiki is becoming tableholics. That said, I'm all for Skuld's proposition. Possibly in the form Name (Location, Campaign), but no tables. — Galil 14:59, 27 August 2006 (CDT)

A month later, but I don't really care, but deciding this is good. Skuld wasn't proposing using a table, he was just using tables to show which was in use and which was proposed. I also hate the "before it's unlocked" part since it's ugly and people are ignoring it anyway. If they don't already understand how the unlocking/availability works that notice isn't enough. --Fyren 03:42, 26 September 2006 (CDT)

the "before it's unlocked" might not be sufficiently enough, but I think it is much better than NOT having it there. Peopel who didnt realize who things work before, might at least be curious and click on the link and learn something. Every little bit helps, and I added that part in beause I was getting sick of reverting stuff. I *think* it's been better lately. -PanSola, LAFTable(sing) 04:12, 26 September 2006 (CDT)

I don't think it's been better lately. --Fyren 04:19, 26 September 2006 (CDT)

Back to the bullet point thing, why use them at all? If you need to go to another line use <br> instead, same thing, no bullet. --Rainith 11:16, 26 September 2006 (CDT)

Br = ugly, bullets = easier to read. Why use html > wikicode? — Skuld 11:21, 26 September 2006 (CDT)

If there's no hierarchy involving the campaign in some way, I agree that there's no need for bullets. I also agree that HTML is pretty ugly in wikitext, so if there'll be no bullets, just insert blank lines to get the final output to be what you want. --Fyren 11:25, 26 September 2006 (CDT)

I just rewrote the S&F and stuck in my preferred formatting for acquisition. Consider it my proposal for this. Basically, for core skills it's what Skuld has in his top table, but with campaign names instead of continents. For non-core skills, the campaign isn't an issue, so it looks like his second table. Of note, I also dropped the phrase "before it's unlocked" since people are still doing it to the articles which have it. Any decline is much more likely to be due to people not playing Prophecies than the warning. The warning does not clarify the situation to people who don't already understand how skill trainers work. --Fyren 06:36, 18 November 2006 (CST)

[edit] using templates for some related skills sections

There's certain clusters of skills are all related to eachother by a common property (spells with armor penetration, multi-target attack skills, damage prevention skills, energy denial skills and the numerous subcategories of damage spells), which would make it practical to just use a template for the related skills section. Then again, categories might be a better idea. -- Gordon Ecker 01:30, 21 July 2006 (CDT)

I'd certainly favor categories for some of these. For instance, damage prevention or healing skills (since they cross classes and attributes) would be fine choices for a category. Possibly broken down (i.e. the utility is being able to say, "I'm a Ranger/Assasin, what are my options for self-healing / other-healing / AoE or multiple attacks / energy denial, etc."). Certainly my current method is to just try to read all the skills, which will become less and less feasible over time (for the core professions). --JoDiamonds 23:46, 23 July 2006 (CDT)

I dunno, you're potentially going to have a lot of new categories, many of which will contain a couple of articles... Currently related skills are listed on the skill page, it's unwieldy to have a link to out energy denial category and having a list and which is exactly the same as what's contained in the category... We already have this kind of info anyway in Category:Skill_quick_references for major smiliar skills. --Xasxas256 00:12, 24 July 2006 (CDT)

On a related note to what Xasxas256 said--For example, if you want to see related skills on Distracting Shot, certainly not all of the related skills that also interrupt should be listed on its "Related Skills" section--as they're already somewhat easily accessible in the Skill quick references as he stated. It is really redundant and not to mention hoggish of space to list ALL of a related field on the Skill's page itself. </end opinion> But on the same subject: What should ultimately be listed in the Related Skills field? I felt silly when I almost tried linking ALL of the skills that Interrupt through the Related Skills field of all revelant skills... It just felt very wrong to do--so I ultimately only listed other interrupts in that Profession's field. So where is the line really drawn, in the higher authorities opinion? -- Feather 09:14, 20 August 2006 (CDT)

In some cases a template would be unwieldy since you might not want to break up the "related skills" and give them headings. In such a case the list may end up being "out of order" with skills not grouped by profession or in the prescribed profession order (not that people pay attention to that anyway). --68.142.14.19 03:57, 24 July 2006 (CDT)

Might I suggest a template add-on(?) such as the mini Profession icons before each related skill as the norm? Its aesthetically pleasing and the images are of small size... One could easily recognize to which class the skill originates from--and it doesn't account for vertical clutter. (Stating the Profession in Text-form uses up a line.) -- Feather 10:21, 14 August 2006 (CDT)

I don't think anyone would complain if you went through and added the icons into the articles. --68.142.14.39 16:02, 14 August 2006 (CDT)

Okies, I can see that Feather (who possibly was 24.23.114.242) has gotten onto this. Anywho, does any one else like/dislike the profession icon? Theres no note on it on the actual article so I thought it was worth furthering this discussion if we're going to add it to the S&F guide. My own opinion is that I don't mind it, it's certainly far perferable to having the skill icon. --Xasxas256 21:51, 14 August 2006 (CDT)

Given that Feather/24.23.114.242 have now done about 100 of them, I've added it to the example and the S&F pages.

Strangely enough, I had started creating those related skills templates you speak of, when Karlos (who seems to be opposed to the templates use... in this part of the wiki) told me about this talk page. So, even if I've started the discussion on my user talk, here are my arguments :

• (fact #1) related skills are actually outdated and unconsistent,
• (fact #2) templates are the bread and butter of a wiki,
• [fact #3) especially when listing repetitive lines (as shorter as a signature or a shortcut for an image, as long as a full article),
• (fact #4) the same template can be tweaked for different usages and presented views (or emphasis as I may call that).
• (fact #5) A few skills would belong to more than one group of "related skills" (but the decision can be made case by case).

• (opinion #1) If you don't use templates here, you miss something useful and those "related skills" sections will stay outdated and give incomplete information to the reader.
• [opinion #2) About the discussion on icon presentation and lost lines, "related skills" are at the end of those pages, with the "see also" section, no matter if they are about a dozen lines long (longer may means you have missed the point of this particular group of skills).
• (opinion #3) "Related skills" are not for any skills, but only those exotic enough not to fit a recognized category (shout, chant, lead attack, binding ritual... and so on) and still have bear an interest.
• (opinion #4) :Two words generally define this "related skills" groupings, like for examples : spell immunity, minion summoning, damage sharing, instant recharge... but you can also havelike distant armor protection, trigger on block or evade.

Anyway I agree those things need guide lines and discussion, but I must also add they are pretty irrevelent comapred to the content (i mean the naming can be changed in less than a hour, by minor updates in all the implicated articles).

So, my proposal is to create those few missing templates (I assume around twenty) and put them in the Related skills category, which talk page would be a better place to discuss the labelling of those templates and their contents. --Leonim 08:56, 27 September 2006 (CDT)

For your "facts:" I won't argue with #1. I reject #2 as simply false. The users are the bread and butter. Templates are merely tools to ease editing and not meant to be used everywhere possible. #3 I reject as related lists shouldn't be that long. #4-5 aren't about why a template helps.

I don't mind changing the formatting of the section, but I do not want to use templates to do it. In short, I don't think templates provide much of a help. I'd much rather see skills in a plain list, sorted by profession. A template doesn't allow insertion into the middle of its list to keep a sorted order. If a related skills list is longer than a few skills, it should be culled to make sure the skill are similar enough. When there's a long list with some kind of logical grouping, it can be done through a quick reference page as Skuld pointed out already. With short lists, it's easy enough to maintain by hand rather than templates. I think we disagree about how long "too long" is, since you mention a dozen as an example. I'm thinking more like 5 skills max for most cases. --Fyren 13:22, 27 September 2006 (CDT)

Anyway, not my role to decide of those things, i'm just proposing. Sysops are against it, no problem, I will use my time elsewhere. :) Could be nice to put the maintenance of those related skills in a todo list and have a talk page to discuss them (since they cover a bunch of articles). By the way, Skuld proposed using quick reference articles instead of templates, does that mean a simple and plain wiki link is allowed in the section (not mentionned in this formatting guide)? --Leonim 06:16, 28 September 2006 (CDT)

Because sysops are arguing against it isn't a good reason to stop arguing, though since three other people have said they don't like it (me, Skuld, Karlos), it might be. I'll never tell someone to stop arguing about it if you think it's better, though. If you make a QR template for it, add a "see also" section with just a plain wikilink to the QR page you make (named "<whatever> skills quick reference"). The minion spells are a good candidate for this, as Skuld said. See Template:Frenzy, Template:Skill box ias, attack speed skills quick reference as references, though use ParserFunctions instead of template-ifs... which reminds me to rewrite some of those. --Fyren 06:49, 28 September 2006 (CDT)

[edit] Skill icons in Related Skills

Why is it far preferable to the skill icon? I would prefer the skill icon. Some people have said that they recognise skill icons better than skill names for the beastiary pages. Also, simply by virtue of the colour of the skill icon is likely more than enough to identify the profession. --Ab.Er.Rant (msg Aberrant80) 22:15, 14 August 2006 (CDT)

Oh god not this vote again! Look it's just the small related skills section do we really need them? It's overload for a small optional section which is often not even there. And hey you voted for the good guys last time! Damn swinging voters! --Xasxas256 22:24, 14 August 2006 (CDT)

Another point is that Bestiary articles normally only concern one profession, there's very few creatures with dual professions. With related skills there could be any profession. At that icon size Ranger and Necro skills can look the same, as can Assassin and Mesmer ones. To me it just adds confusion, adds a lot of work, makes standardisation a lot more difficult without much payoff. --Xasxas256

Ok, ok, I'll just... swing back! No to skill icons! :P --Ab.Er.Rant (msg Aberrant80) 22:58, 15 August 2006 (CDT)

Cheers big ears! ;) --Xasxas256 23:16, 15 August 2006 (CDT)

[edit] Summary of When/Where Decision Were Made

I haven't mucked about with skills in a long time, and looking at them now, I wouldn't know where to start.

When did this subtemplate nonsense become standard? I thought I, Karlos, Nunix, and <insert random other oldtimer names> shot this stuff down back when Ollj suggested it a year ago. It took me 10 minutes to figure out how to edit a skill article—there's absolutely no way Random McNewbie will be able to use them.

*mutters something about damned kids wrecking the place*

—Tanaric 06:06, 2 August 2006 (CDT)

lol, have I mentioned how glad I am that you're back Tanaric? :) <LordBiro>/<Talk> 15:48, 2 August 2006 (CDT)

it is a bit daunting, but it has it's uses. consider the attack speed skills quick reference. all that data is pulled from the skill templates, dynamically. should another IWAY nerf happen, one edit on template:"I Will Avenge You!" fixes that and two or three other references. --Honorable Sarah 15:56, 2 August 2006 (CDT)

The coder in me (and that's a big part of me!) absolutely loves the elegance of that solution. I'm not saying it isn't pretty or that it doesn't work. However, it's unwiki. The point of wiki is that, since we have a million pageviews every day anyway, if something changes skill-wise, somebody will see the wrong information on any page where it's redundant and fix it.

The current status quo of template use establishes an editor class within the wiki. There are editors who know what they are doing and therefore can contribute and control the direction of this place, and there's the rest of us, who are so in the dark that our voices are essentially meaningless, because we lack the ability to create change anyway. You guys with intimate knowledge of templates are the bourgeoisie, and I'm trying to get the proletariat to rise up against you. :)

In all seriousness, though, I believe the barrier to entry created by this current method far outweighs any advantage they can possibly provide. As Karlos noted on his talk page, much of our information is out of date simply because people don't know how to edit anymore. It's sad, but we were more current back when Nunix, Biro, Karlos, and I were writing most of the content -- there were a bloody ton of manhours dumped into it, and mistakes were definitely made, but there were so many anon and new member edits keeping us in line that it didn't matter. We've scared away a lot of these single-edit wonders, and I think the GuildWiki is weakened as a result. —Tanaric 04:25, 3 August 2006 (CDT)

I completely agree, Tanaric. I believe I said so during the discussion too, but my objections were not heard. I wish those who are now voicing this opinion would have said something back then instead of waiting 'till now. --  Bishop [rap|con] 17:11, 4 August 2006 (CDT)

Reading up on the discussion, the above statement is not quite fair. There was indeed voices raised in concern (and right now I can't even seem to find where I objected although I'm sure I did). Just not loudly enough, I guess. --  Bishop [rap|con] 17:17, 4 August 2006 (CDT)

Most of the relavent discussion can be found here and later GuildWiki_talk:Community_Portal/Archive_5#A New Section for the Bigger Issue - Split/Subst/Redundant. Much of those discussion took place when implementation started on Mesmer skills, but haven't been completely spread over to other professions yet. Anything I currently can think of to say on the matter have been expressed in those two discussions. -PanSola, LAFTable(sing) 16:39, 2 August 2006 (CDT)

BTW, maybe we should start some kind of campaign to promote contributors to edit via the edit section links. It helps auto-generate a edit summary and makes Recentchanges-patrolling much easier anyways. It also would've saved Tanaric 10 minutes of his time. -PanSola, LAFTable(sing) 16:43, 2 August 2006 (CDT)

Section edit links are optional—users have the ability to turn them off in Preferences. In addition, I think some of the other skins don't offer them at all. We can't rely on those mechanics to make the wiki functional. —Tanaric 04:25, 3 August 2006 (CDT)

Personally, as I'm sure I've said before, I don't think that making the wiki less redundant is worth the price of increased complexity. <LordBiro>/<Talk> 14:06, 3 August 2006 (CDT)

some templates are harder to understand then others. i personally do not wish to repeat my experiances with attack speed skills quick reference, i had to ask another user to create the appropreate template for me (the fact that it was an anon that actually created template:skill box ias is rather... counterintuitive). however, some templates, like Template:skill bar and template:TOCright are great effort savers, and make it easier to edit. the skills data is fairly straight forward, all game data is stored in the template, and usage/progression/experimental data is stored in the main namespace. the game data will only change with a rebalance, which is fairly rare (a handfull of times in the past six months), and the bulk of the changes are to the main namespace. The Deep and Urgoz's Warren (Mission) are strangely free of the type of template we are talking about. --Honorable Sarah 14:24, 3 August 2006 (CDT)

[edit] Make it easier to edit skill articles

Let me repeat the above critisism. When looking at the recent skill balance, it took much longer than the usual 1-2 hours till skills where updated and (I might be wrong about this) there were almost no edits by anon contributers. I perfectly understand the usefullness of templates, but more should be done to counter their disadvantages. Looking at this article page, there is nothing to help a first time user understand why there is a template, how it works and how to get to edit it. A basic "you need to click here to edit skill data" is missing. Ideally that line would also be found (commented-out) in all the skill articles, to make anon-editors aware of what to do to edit the skill data. --Xeeron 06:45, 15 September 2006 (CDT)

I saw several anon edits. I think the extremely large download had more to do with the delay this time. Using -image took close to 45 minutes to complete for me.

I really don't understand where you mean for inclusion of the "you need to click here to edit skill data" comment. There are section "edit" links, just as in every other article. Can you clarify? It's likely just too early in the morning here, and I'm just not awake enough to follow without a clearer explaination of what you mean.  ;-D --- Barek (talk • contribs) - 08:28, 15 September 2006 (CDT)

Section edit links are disable-able by skin and preferences, and probably should not be relied upon. —Tanaric 10:55, 15 September 2006 (CDT)

If disabled via preferences or skin, it would be a site wide issue for the user, not specific to skills. Xeeron mentioned the link was to benefit first time / newer users, who would be most likely to be using the default skins and not to have changed the preferences to hide section edit links.

Keep in mind, I'm not saying it's a bad idea. I just want to understand better what is being proposed and why it's being suggested. --- Barek (talk • contribs) - 11:07, 15 September 2006 (CDT)

I wouldn't be opposed to having some comments in the article saying to edit the template instead of the article itself. It might be a good idea to say something as standard in skill articles, such as:

"Skill data is not held directly in the skill article, as in some situations we need to use this information in other places. If you would like to change any of this skills' details please go to [[Template:Skill name]]".

Is this the kind of thing you were suggesting Xeeron? <LordBiro>/<Talk> 11:44, 15 September 2006 (CDT)

Yes exactly. I clicked on the normal edit of a skill first when I wanted to check something earlier and didnt find the data. Of course then I remembered that it was outsourced to a template, but any new user would likely not come to the conclusion that fast. The edit link in the section is there, but unless you know how the wiki works, you will never get why you have to click there instead of the normal edit button. That is what should be explained in comments. --Xeeron 12:50, 15 September 2006 (CDT)

*sigh* --Karlos 08:50, 27 September 2006 (CDT)

Just to point out, I changed the [edit] link to say [edit skill details] in my proposed template. I can still add a comment in the article text pretty easily with a bot saying to edit the template. The edit link the template generates (whether the old one that looks like a section edit or the one in the proposal) can't be disabled in preferences because it's not a real section edit link. --Fyren 20:28, 8 October 2006 (CDT)

[edit] Typo?

The subst comment in the article says "{{subst:skill box qu" Does that make sense? --Karlos 08:51, 27 September 2006 (CDT)

It's correct as it is. --Fyren 13:29, 27 September 2006 (CDT)

[edit] Skill box revamp

So, there's a couple changes I've been wanting to make to the basic template:skill box. I'll separate them out into subheadings for discussion since they're all independent. My mostly-everything-in-one example is at GuildWiki:Sandbox/Skill box. Its talk page has a list of example skills (which will look broken until the CSS is site wide or you put the CSS in your user space, see the CSS section below) in the sandbox that use the template and a listing of changes (which I think are all described fully here). --Fyren 20:15, 5 October 2006 (CDT)

Doesn't seem like anyone has specifically objected to these changes. Still going to think about the special skills thing more. I'm going to plan to have these changes live by noon on the 23rd (the Monday before Nightfall release). If anyone wants anything else added, speaking up now would be good. --Fyren 21:57, 13 October 2006 (CDT)

So, I have a script ready to edit all the skill templates and articles. I tested it against a random selection of 50 skills (on my test wiki, not here) so I'm confident that I've caught most weirdness. It removes the progression from the article, puts the data into the template, fixes a bunch of skill article formatting things (old noincludes, cats that shouldn't be there, extra whitespace, headings with wrong case), and changes the skill templates from valX/statX (and a couple formatting things). Unless someone suggests changes to be made, on Thursday or Friday morning at around 5 AM EST I'm going to apply the changes. --Fyren 08:25, 14 October 2006 (CDT)

[edit] Auto progressions

Since we've got PF now and I've waited a long while to make sure there's nothing horribly wrong that would make us want to get rid of it, I think we should auto-generate the progression tables. I've implemented this by putting it straight into the skill box template. See GuildWiki:Sandbox/Symbiosis and its source. The three progression lines/nine progression parameters are the data used to generate the table for symbiosis. This isn't the only way to do it, but putting all the skill data into the skill templates seems like a good idea to me (as opposed to having most of it in the templates and progression data in the articles).

This would solve the problem of people making up data, inconsistent use of ? and N/A, and people filling in numbers for unattainable attribute ranks. It should also cut down on actual errors since there are only two numbers to check per range.

For users who don't edit the skill data templates or progression tables, this change is invisible besides that the progression sections will disappear from the articles. To edit a progression table, the only things to change are the row headings and the values at 0 or 15, all of which would be located in the templates. --Fyren 20:15, 5 October 2006 (CDT)

Sounds ok to me. -- (talk) 00:21, 6 October 2006 (CDT)

Do all progressions increase in the same way? As long as there are no exceptions to the way in which values are calculated from attributes then I think this is an excellent idea. Even if there are some exceptions to the rule, as long as we would be able to allow for these exceptions then I think this would be great. <LordBiro>/<Talk> 04:14, 6 October 2006 (CDT)

There are no exceptions. --Fyren 04:41, 6 October 2006 (CDT)

If that's the case then I see no problem with implementing this. <LordBiro>/<Talk> 05:24, 6 October 2006 (CDT)

[edit] valX/statX

Right now, upkeep/sacrifice/energy/adrenaline/activation/recharge need to be manually given the right "X." That is, recharge is always val3/stat3 (so in a template you always see "val3 = Recharge" and "stat3 = 5"). The change is to just have "recharge = 5." Compare the source for the real unyielding aura template to the source for my example UY template.

I think the existing parameter names are slightly confusing and much more complex than necessary. When users misnumber a stat, then in the all the various skill boxes, the stat will show up in the wrong place. The positioning shouldn't be left to the user but to the template.

For users who don't edit the skill data templates, this change is invisible. I think it makes the templates more readable. As mentioned, this allows other templates (ones like template:skill box qr) to format the stats how they want, which is good. --Fyren 20:15, 5 October 2006 (CDT)

I always wondered why the names were so weird. Agreed. -- (talk) 00:21, 6 October 2006 (CDT)

Good idea. In my old one I wanted this ^^ — Skuld 01:12, 6 October 2006 (CDT)

Yeah, it's ridiculous that it was ever implemented this way really. <LordBiro>/<Talk> 05:25, 6 October 2006 (CDT)

The rational behind the original design was to minimize the use of logical operators (IF's) in the template. In fact, we did NOT even have the If-Then-Else template back then, and therefore the alternative would've been more ridiculous. As a general principle, I still prefer to minimize the use of IF's, but now with parser functions it's much less important than it used to be. -PanSola, LAFTable(sing) 00:43, 9 October 2006 (CDT)

[edit] Formatting

These are all independent of each other, of course, but I'll lump them together.

I don't like it displaying profession "common" or attribute "no attribute." I especially dislike that it links No Attribute. I'd bet the only reason common isn't linked is that's already a redirect for something else. I'd prefer to remove the rows entirely for such skills. See Resurrection Signet versus my example GuildWiki:Sandbox/Resurrection Signet. I won't be crushed if people want the rows to stay.

Leaving the rows, changing the values to plain "common" or "unlinked" (no links). --Fyren 00:50, 14 October 2006 (CDT)

In my example, I set fixed widths for the cells containing the energy/activation/etc. stats, I right aligned the text "type:" and such, and I changed the "[edit]" link that went to the templates into "[edit skill details]" (and changed its position a little). I can't really imagine opposition to these three changes, but maybe someone will surprise me.

These changes would, of course, change how the boxes are displayed. But for editors, there's no change to the data templates or articles. --Fyren 20:15, 5 October 2006 (CDT)

You should add some padding on the edges of the title (in the skill box). About the rows below the icon, I prefer the actual display, but it is a matter of taste and web-browsing general use.

"Title?" The skill name? "Actual display?" --Fyren 21:19, 5 October 2006 (CDT)

I would like to keep the No Attribute displayed. When I look at a skill and don't know if it is tied to an attribute, it takes me more time to realise that there is no attribute field than it would take to find the 'No Attribute' attribute field.

I would also like the boxes to have borders as as before. Your skillboxs don't have borders. (Using Opera) -- (talk) 00:21, 6 October 2006 (CDT)

Argh. I didn't test the recent border changes anywhere but Firefox. --Fyren 01:00, 6 October 2006 (CDT)

So, I fiddled with it but don't have Opera. Someone with Opera (or simply less lazy than me) check it and report back? --Fyren 01:22, 6 October 2006 (CDT)

It works now. -- (talk) 18:23, 7 October 2006 (CDT)

[edit] Special skills

← Moved from Category talk:Snow fighting skills

With the change to the template version of skills, all of these show up in the normal skill lists, making them look like normal skills. Here is a prove of someone getting confused. I dont know how to change the template, but it needs to move these out of the normal skill categories. --Xeeron 06:08, 2 October 2006 (CDT)

I've been thinking about this. We either have to make a new template for "special" skills or add a parameter to not apply the normal categorization (and then do it by hand in the skill articles). I'm not sure if there are any better ways. --Fyren 09:57, 2 October 2006 (CDT)

How about not using a template at all since the reasons to use templates in the first place do not apply? Or is there any reason I am missing? --Xeeron 10:07, 2 October 2006 (CDT)

They're still skills and have descriptions, icons, costs, activations, and recharges. --Fyren 10:10, 2 October 2006 (CDT)

Can't the code from the template simply be placed on the article page itself? Well if it doesnt work, I'd vote for a special template: Better not to complicate the normal one just to account for special event skills. --Xeeron 11:04, 6 October 2006 (CDT)

You could copy and paste the table code, but it's actually kind of long. I'm not sure how much you could cut out. It would be better to change the existing template to take something like "nocats = yes" than make a new template if categorization is the only problem. --Fyren 16:11, 6 October 2006 (CDT)

I think it would make sense to make the appearance of non-standard skills different. Either by giving the image itself a different border (blue or red or something) or changing the background colour of the skill box from green to something else, or doing both. I don't like the idea of "nocats = yes", it should be "special = yes" or "non-standard = yes" or something. <LordBiro>/<Talk> 17:41, 6 October 2006 (CDT)

Depending on what we want changed for certain skills, maybe. If all it does is remove categories, then nocats is a better name than special. If it does more, then sure. --Fyren 17:53, 6 October 2006 (CDT)

I disagree there. The parameters you pass to a template should describe what the item IS, not how it should behave. For example, you might be tempted to make a template with a parameter "nocats", because the decided way of handling special skills is to make sure they don't appear in any categories. Later on it might be decided that the way special skills should be distinguished is that they should still be included in categories, but they have some special decoration on them. If you had originally called the parameter "nocats" then this would no longer make sense and you'd have to go through every article and change "nocats" to "decoration" or something. But the item is still a special skill, that hasn't changed and never will. If you just use "special-skill" as a parameter then regardless of how we treat special skills it will always be a sensible parameter. <LordBiro>/<Talk> 07:34, 8 October 2006 (CDT)

I don't mean to be rude, but that makes no sense. I don't even know how to question it. What item? It's a MediaWiki template. It's not an abstraction of a skill. --Fyren 07:59, 8 October 2006 (CDT)

Ok... I don't see what doesn't make sense. It makes perfect sense to me to abstract the behaviour of a template away from the place that the template is called. In this case skill articles.

I know I'm repeating myself here, but I don't care.

Say we discuss it here and decide that special skills should not be in categories. Then you alter the skill template to make use of a parameter called "nocats" and edit every special skills page so that it says "nocats = true" or whatever. This would accomplish the goal. Then a month later we decide, actually, they should be in the same categories as regular skills, but they should have some other difference, such as a style difference. So you alter the template so that "nocats" doesn't do anything, and you add a new parameter called "different-style" and add "different-style = true" to every skill article.

That process is fine, but if you just used the template "special-skill = true" then you wouldn't have to go through every article again in the future and replace "nocats" with "different-style".

If you don't agree with that then that's fine. If you don't understand that though then I don't know what else to say. It's just a way of saving time in the future, should things change. <LordBiro>/<Talk> 13:36, 8 October 2006 (CDT)

That sounds nothing like what you said before, but at least I can address it. If later, rather than changing the style of them, you want to make different styles for holiday skills and for celestial skills and for cheese-related skills, you still have to go through and edit the all skills. If later we want special skills to not be special, we don't just edit the template (and perhaps we don't edit the template at all) to remove the functionality. We go through and remove all the special = trues.

If we have nocats and you later want to actually categorize, we (again) don't edit the template. We would go through all the skills. In neither case is it surprising or a design flaw. If we want to completely reverse changes we made, then it'll have to go through as much effort as it did to add the changes (that is, removing "nocats" or "special" from each to match the adding).

I don't want to try to make templates smarter than they have to be. I'd rather specify every little detail then leave it up to the template. Being smart has resulted in things like this creeping in (note the type and cat parameters... and the "part" parameter which never actually did anything useful for any skill, which is why I'm discussing changes rather than pushing them out, not to badmouth what Pan did with the creation of the current skill box). nocats will do exactly one thing depending on exactly one input. It won't break and it's highly unlikely its functionality will ever change, only where you want to use it. --Fyren 17:26, 8 October 2006 (CDT)

Reading through my two posts they sound pretty much identical to me, but ok :P

I'm not really arguing that we should make the templates complicated, and I don't beleive that using a parameter name such as "special-skill" instead of "nocats" makes the template any more complicated. In fact I think it makes perfect sense to do so. I can understand where you're coming from but I don't agree with it. I can't really think of much more to say, and it appears to just be us two here, so I'll just leave it at that. <LordBiro>/<Talk> 18:05, 8 October 2006 (CDT)

Just for the record I would also be in favour of a parameter like "type = special". Just felt I should say that :) hehe <LordBiro>/<Talk> 20:41, 8 October 2006 (CDT)

[edit] CSS

Most of the changes to the current skill box or skill box qr templates have been style changes. That is, the tables and information displayed haven't changed, only things like cell widths, alignments, paddings, and other things that could be separated out. I've factored it out (for the main skill box and the progression tables, not for all the other skill templates yet) by slapping a class on a lot of things so it can be placed in MediaWiki:Common.css. This is a site-wide stylesheet that's already loaded by every user (though it contains nothing but a comment right now). Edits can be made to the stylesheet as opposed to the template which is a significant gain when considering CPU and database load because of work work the wiki does to track changes in templates that affect all the pages that include it. Bandwidth-wise, the CSS is currently about 1.9k. Since it'll be cached client-side by browsers, this will be a one-time cost till the browser cache is cleared. For someone viewing skill articles, it'll actually be a bandwidth-saver since the inline styles won't be transferred for every skill.

I tested it out already in Firefox, IE6, and Opera. I didn't really change anything, so I don't think there's much chance of a problem. To test it out, copy the contents of my monobook.css to your monobook.css or your gamewikis.css, depending on your skin, and viewing the skills linked on GuildWiki talk:Sandbox/Skill box. I'd like to hear comments and suggestions about what I've classed and what I haven't or how I've otherwise arranged things. Web design isn't one of my hobbies. --Fyren 05:52, 15 October 2006 (CDT)

[edit] Other

Assuming progression data gets moved inside the skill templates, there's still duplicated information in the description: the ranges in the descriptions. We can calculate them, but we can't splice them in. StringFunctions would let us. On my test wiki at http://MYUSERNAME.nimh.net/wiki, check out the build JS demo and any of the example skills. The thing to notice is that when you toggle the build there (as opposed to the test I ran here), the QR-like view has no ranges but instead actual values. The numbers for the skill ranges work in the same way, though you can't tell just by looking at the skill articles, so check the source for a skill data template to see where "RANGEX" is used in descriptions as placeholders. I'm not putting the SF-related stuff forth as a proposal yet, but I'd like to hear if people think it's worth doing. Adding SF shouldn't be a bad thing but it would require more thought (the version I run on my wiki has most of the functionality stripped out, only keeping pos/len/substr). --Fyren 20:15, 5 October 2006 (CDT)

That is pretty cool, but I don't know how useful it is. It does reduce redundancy, but that's not much of an issue since the two values are both inside the same template. <LordBiro>/<Talk> 04:20, 6 October 2006 (CDT)

The main use is for use in a hypothetical build template to fill in the specific value. The skill description ranges are just sort of a "why not, this is one less place for someone to screw up when updating numbers." --Fyren 21:44, 13 October 2006 (CDT)

[edit] Trivia mention in skill articles

I'm not a big fan of the trivia sections; but assuming that we use them, I disagree with where the information is placed per the current guidelines. By this, the trivia belongs in the Notes section, which is shown in the example article as belonging above the progression section. To me, trivia, if included at all, is a very low priority and should be placed below related skills at the end of the article. --- Barek (talk • contribs) - 12:07, 6 October 2006 (CDT)

Currently the notes are usually under the progression and trivia under the notes. The guidelines should be changed to reflect that. -- (talk) 13:27, 6 October 2006 (CDT)

[edit] Skill capture and other formatting questions.

I also just noticed that the current example no longer shows that it should document from what bosses you can capture elites. It used to have a "signet of capture" section, but that was removed. While I can understand not liting it for most skills, this section should exist for elites, and the template should mention that (it is still mentioned in the guideline, just not in the example). --- Barek (talk • contribs) - 12:19, 6 October 2006 (CDT)

Elite skills should have the bosses listed, but normal skills in my opinnion not. -- (talk) 13:30, 6 October 2006 (CDT)

I think having signet of capture lists makes sense in any situation where you can cap it before you can buy it. <LordBiro>/<Talk> 07:36, 8 October 2006 (CDT)

[ edit] Difference between "health per second" and "health regeneration"

Just noted this on "Fall Back!": It seems that the skill template does not differentiate between regen and hps, but it should, since regen is more then hps and the interaction with regen/degen caps is different, too. --Xeeron 09:45, 10 October 2006 (CDT)

That's because someone decided to name it "health regeneration." The template doesn't fill in the effect names for progression rows. --Fyren 21:42, 13 October 2006 (CDT)

[edit] Related Builds Section

I've added a "Related builds" section to several elite skills (examples: Barrage and Spiteful Spirit, listing Tested/Favored builds using that skill.

When I or my guildies first encounter an elite skill, our initial question is: How do I create a build around this? The logical search path is to look up the skill on GuildWiki, and then follow links to examples of quality builds based around it. The vast majority of builds are constructed around an elite skill, and having these sections is similar in concept to the current "Related skills" sections.

The amount of effort going into this is minor; it took me all of twenty minutes today to added "Related builds" to a dozen or so Necromancer and Ranger skills. I'm more than happy to do this for other classes, and maintain the sections by watching the Tested/Favored builds page. — ChaoticCoyote 21:59, 20 October 2006 (CDT)

The idea is fine, but the problem is the number of builds that use the elite. The list may get too long. Picking only certain builds will be completely arbitrary. --Fyren 22:07, 20 October 2006 (CDT)

I doubt there will be more than a half-dozen builds for any given elite, and then only for a very few "popular" elites like Barrage. — ChaoticCoyote 22:17, 20 October 2006 (CDT)

I just hit "What Links Here" from the template and scan through builds, personally. - Greven 22:08, 20 October 2006 (CDT)

That technique isn't obvious to casual Wikians — and a skill may be linked from lots of places, including unfavored and abandoned builds. A "Related builds" section provides clear links to tested/favored builds that, in theory, make effective use of the skill. — ChaoticCoyote 22:17, 20 October 2006 (CDT)

Yes, non-wiki experts will not get that. Obviously, only tested builds should be linked, that will keep down the number of builds per skill as well. I doubt we have more than 5 tested builds for all but very few elite skills. --Xeeron 04:45, 21 October 2006 (CDT)

Might it make sense to create {{Builds using Spiteful Spirit}} or something? This would also be very useful for finding builds that have been affected by changes to elites in game updates. <LordBiro>/<Talk> 07:46, 21 October 2006 (CDT)

I sense never-going-to-be-properly-updatedness. --Fyren 08:06, 21 October 2006 (CDT)

Can you explain how exactly you want to use that template Biro? The updates are an issue, but then, builds are only very rarely moved out of tested, so checking what-links-here when moving should help that. --Xeeron 08:09, 21 October 2006 (CDT)

Hmmm just another idea: There could be one site listing all (tested) builds ordered by elite (with links from the skill pages to that site). Should make updating easier. --Xeeron 08:12, 21 October 2006 (CDT)

My thinking was that the template could be included in both the skill article and the build articles. That way if you see a build using Word of Healing you could find other builds using that elite.

I'm not sure what you mean by "another site". Do you mean a seperate web site to this one? <LordBiro>/<Talk> 08:30, 21 October 2006 (CDT)

No, just one big article instead of lots of small sections on the skill pages. --Xeeron 10:14, 21 October 2006 (CDT)

There hasnt been any discussion regarding this in awhile, is there any news about the possibility of getting this added? The list may get long for the more popular elites, but not EVERY build need be listed, perhaps just the "vetted" builds.--Saranis 12:40, 17 January 2007 (CST)

I was thinking of something like a "Original Builds" category, sorta like a place to put like your direct Smite Monks or Glass Arrow Rangers or Ward Against Harm eles and stuff like that. — Rapta (talk|contribs) 23:11, 31 January 2007 (CST)

Moved from a Duplicate Article
Newer players can find it useful to see a skill used in order to get a feel for it. The closest we can get to this on the wiki is to link to tested builds from the skill page (bottom of page).

There is some tenative support for this from the group I play with, what sort of procedure is required to get this officially considered?

Click on "what links here" and use your browser search to search for "build." You won't get only tested builds, but skill articles will get insanely cluttered if you add every tested build that uses a skill. --Fyren 23:42, 9 February 2007 (CST)

I know this has come up before (just scroll up a ways for one instance), and while it's technically tricky, maybe impossible, to implement the demand is there. I had one idea: Is there any way to create, via a template I suppose, a search link that specifies a search for the skill name and limits the search to the build namespace? I guess it depends on whether the search page can take a namespace as an URL variable. I used to do stuff like that all the time in ColdFusion, but obviously working inside the confines of the wiki software is a different ballgame. Anyway, the idea is that, if this template-created link is doable, it would be an easy "search the builds section for references to this skill" link. I'll leave to the experts (coughFyrencough) to say if it's doable. — HarshLanguage 21:46, 10 February 2007 (CST)

You can do, say, http://gw.gamewikis.org/wiki/Special:Search?ns100=1&search=Flare&searchx=Search but it searches by words, not phrases. So searching for any of the "judgment" skills will end up with all of them showing in the results. --Fyren 02:50, 11 February 2007 (CST)

Could we do something cunning with templates, similar to how the skill quick references are done? Just set up a template for a build's skills, then bung a link on every skills page to an auto-filtered list/other clever execution? Or am I barking up the wrong tree? --NieA7 16:01, 11 February 2007 (CST)

Quick references are all manually created. Someone decided which skills should be in them and edited the QR page, adding a line for each and editing the skill's template to add the data. We use the templates the way we do for them so we don't have to go through every QR page and verify data when there's a patch; unless a skill's effect completely changes, you just edit the skill's template. --Fyren 17:08, 11 February 2007 (CST)

So can MediaWiki dynamically generate pages? I know a fair bit of SQL but nothing about wiki mechanics, so I'm not sure what is and isn't possible... --NieA7 18:13, 11 February 2007 (CST)

Every single page is dynamically generated, though you may get a version cached by squid or MW. I don't think changing the code for "what links here" to allow filtering by namespace would be hard, but I'd have to look into why it doesn't do that already. It might be there's a performance concern or it might just be that no one really wanted the feature or wanted to implement it. --Fyren 18:45, 11 February 2007 (CST)

i've had a lot of success with the following google search:

http://www.google.com/search?hl=en&q=site%3Agw.gamewikis.org%2Fwiki%2F+build+%22successfully+vetted%22+%22vital+boon%22&btnG=Search

where the "vital+boon" can be replaced by any skill name (including phrases) --Deflective 04:28, 13 February 2007 (CST)

[edit] Rewrite

I rewrote the article to mostly reflect the current state of skill articles and separate out the template information. As far as I can tell, the parts that signficantly vary are the acquisition (see #Aquisition), where our articles also wildly vary, and the related skills lists, where the formatting varies (some have skill icons, some have profession icons, most/all have bullets). --Fyren 06:47, 18 November 2006 (CST)

[edit] Related Skills section

Currently, the related skills section shows to list the skills as the profession followed by a link to the skill. But, it was just mentioned to me that this was just thrown in as the general practice at the time of documentation, and never really discussed. A user had started to change the formatting in articles, so we should confirm the preferred formatting.
So, what formatting should we use for the related skills?

1. Mending
2. Mending
3. Mending

The S&F currently shows the first one. I just wanted to confirm the general concensus. --- Barek (talk • contribs) - 19:31, 14 December 2006 (CST)

Oh, I actually changed it to say "no bullets" as an aesthetic issue. You don't need "<bullet> <icon> <text>", the icon serves the purpose a bullet would. As far as I know, every related section uses a bullet, whether with a profession icon or a skill icon. --Fyren 19:45, 14 December 2006 (CST)

The only argument that's been made about this beyond aesthetics is that we started using skill icons for bestiary articles since almost every monster only uses skills from one profession, making the profession icons redundant, but related skills sections often contain skills from multiple professions. I'm in favor of profession icons for this reason. Profession icons make it explicit while someone has to know the general themes of the skill icons to get the same information. The skill name is already there; I don't think people will know the icon but not the name or be able to recognize the icon at 25x25 faster than reading the name. --Fyren 19:50, 14 December 2006 (CST)

For pretty much the same reason, I tend to prefer either option 1 or 3 - I'm indifferent on bullets. I do see your point about them, and have no objection to omitting them. --- Barek (talk • contribs) - 10:20, 15 December 2006 (CST)

[ edit] Finally done, fixed the formating on the skill pages

A few changes were done, i tried to follow the policy as close as i could.

• Yes, i changed all related skills, to *{{skill icon|skillname}} ([[Elite]])
  • This will allow a lot more control over that section of the wiki
  • Skill icon was already in the system so i just reused that.
  • I did this because now a bot can be run through and change that, to something like *{{related skill|skillname}} ([[Elite]]). Using this, the entire related skill list on each article page can now be controlled centrally and changed to something more fitting, even the original look of it. with the and so on.
  • Formating looks better with the * at the start with related skills btw
• I left the Acquisition note in Attuned Was Songkai & Clamor of Souls next to the boss location information
  • This was the only article i did it with and i think it should be left this way, i went caping one of these skills once and never realized there was another boss there till i got to the location and it really pissed me off >:|. Putting this in the notes wont be acceptable, it is not visually easy to see.
• Related builds
  • These are now the very last item on the article page, even below related articles. Only vetted builds should be in this section, i found a few that were still in the untested section.
• Category:Need Nightfall Skill Trainer
  • This list will contain all nightfall skills that require a skill trainer to be listed
• Category:Need Factions Skill Trainer
  • This list will contain all factions skills that require a skill trainer to be listed
• next chapter/campaign recommendations
  • put {{skill-stub}} at the top of the article page and Category:Need (next chapter name) Skill Trainer at the bottom of all new skills and core skills
• Explosive Growth
  • Now this is one messed up page, newlines will not register at all. I posted this on fyren's talk page so he may or may not look at it. Idiot self, went to bed, went shit i know whats wrong with that and now its fixed.
• Other sections not in the policy
  • I found a few articles with ==Clarify== and ==Energy Management== or something similar. I shoved these into the Notes section under a sub-sub-section like ===Clarify===, it is visually fine and fits into the policy better.

Oh and on a last note, whoever was editing the mesmer skill articles, i hate you :O Xeon 11:16, 24 December 2006 (CST)

My mistake, i left one other note in the acquisition section on the page Echo -- Xeon 03:16, 2 January 2007 (CST)

If you're asking about changing the S&F itself, go ahead. If you're asking for input on your changes, the categories shouldn't be capitalized and I don't like the acquisition notes in the two ritualist skills. I left related builds out of the S&F because in most cases I don't think it's a good idea. Some elites will be used in a zillion builds even counting only vetted builds. I haven't actively removed the sections when I see them. --Fyren 03:42, 2 January 2007 (CST)

Input was what i was looking for. Capitalization was a mistake i didn't realize till more then half way through, by then it would of taken to much effort to change them all, it is also meant to be a temporary category until all the skill trainers are added, so it will be phased out eventually. i will leave the related builds section up to you to decide on if it should be kept or not. For the ritualist cap locations note, they could be put into the notes section possibly with something like

• Acquisition: Another boss is found blah blah

i think it should be stressed in some way that that there is another boss at this location, again i will leave that up to you to decide. -- Xeon 04:05, 2 January 2007 (CST)

I'm strongly against a related builds section. — Skuld 05:09, 2 January 2007 (CST)

hmm, i was never for them, i just had no idea what to do with them, so i just formated them so they at least fit in better. So thats fyren and skuld saying no, might as well remove them as we see them then :P -- Xeon 05:14, 2 January 2007 (CST)

Related builds section was initially discussed here: GuildWiki talk:Builds#Related Builds Section (and it was pointed out there that it was in the wrong place, don't know if it ever came up here). So long as it's done only for elites and favoured builds I think it's a pretty good idea really, good example of cross referencing. --NieA7 05:40, 2 January 2007 (CST)

Besides the failure of the build policy to provide rating of builds in a sensible way (a number of opinions countable on one hand do not constitute saying "the community" has vetted or dumped a build), there's no particular reason to list some builds and not others even among vetted builds. Certain elites skills probably already have an abundance of builds (like popular monk elites). Simply having the elite on the bar isn't enough. --Fyren 06:30, 2 January 2007 (CST)

If you can think of a better vetting procedure please post it before we all go mad. Anyway, it's not a case of improving the build page, it's a case of improving the elite page - it can be very useful to see what kind of context certain skills work well in, for some skills it's obvious but by no means all (especially when combined with another profession). Just because one or two elites are used in lots of builds doesn't mean that everything is as clear as the day is long. --NieA7 06:47, 2 January 2007 (CST)

It means unless you have some sort of criteria for why some builds are listed and some aren't, you shouldn't be listing builds. How good the builds are is clearly not something the wiki is judging well. --Fyren 07:00, 2 January 2007 (CST)

True, but for most (and probably the vast majority) of elites there's only going to be a couple of builds anyway. For the popular stuff (Elemental Attunement, Echo, Spiteful Spirit etc) we could either list everything (not difficult, but ugly) or just discuss it on the elite's talk page. I don't know, it's just seems like a useful, nice feature to have - too nice to just cut out due to the lack of a policy (and while I've only really been paying attention to builds policy, it seems like it's very difficult to get anything finally approved. Too many cooks and all that). --NieA7 07:25, 2 January 2007 (CST)

Maybe we should just wait till the build section sorts itself out and then see if the skill article pages can build on top of that. -- Xeon 08:35, 2 January 2007 (CST)

If previous performance is any guide to the future that could be a hell of a long wait, unfortunately. --NieA7 09:15, 2 January 2007 (CST)

Just throwing a wild question out. Is it possible to list only builds that have the skill on its skill bar some how? -- Xeon 09:31, 2 January 2007 (CST)

[edit] Acquisition Redux

After having cleaned up some extraneous trainers added to several Rit skills, and checking here for a style on exactly which trainers are listed, I see some need for clarification in the skill trainer section of skills articles. At first I thought the "rule" was first trainer who sells the skill per campaign only. And maybe also the first trainer foreign characters encounter who sells it. Now I'm not sure that's really the style. But I think it should be, for clarity and brevity.

However, that leaves the two big confusion-generating aspects of skill trainers unaccounted for: 1) All trainers after that first trainer will also sell that skill, and 2) all trainers in the campaign will sell the skill if it's been unlocked on the account already. How do we succinctly but clearly notify readers and editors that only the first trainer should be listed? Previous attempts didn't quite work (see GuildWiki talk:Style and formatting/Skills#Acquisition above).

So I came up with a simple and I think elegant solution that solves both problems. Essentially, add a bullet point after the first trainer that explicitly says that each subsequent trainer will also have the skill, or all trainers if the skill has been unlocked. Add a slightly modified version that applies to Core skills, and voila! I created 2 example pages to show what I'm suggesting: User:HarshLanguage/Skill Acquisition Style Sandbox for a single campaign skill, and User:HarshLanguage/Skill Acquisition Style Sandbox 2 for a core skill. Here's another example:

Skill Trainers:

• Tohn (Kamadan, Jewel of Istan)
• Subsequent Nightfall skill trainers. If already unlocked, all Nightfall skill trainers

Thoughts? Suggestions? I think it would save us a lot of future editing and confusion. The change could be rolled out by hand over time, unless it's bottable (I don't know anything about bot capabilities). — HarshLanguage 18:18, 20 January 2007 (CST)

It has never been verified that all later trainers will offer skills an earlier trainer offered. --Fyren 18:39, 20 January 2007 (CST)

Really? I thought that was a verified thing. All the Skill trainer pages I've looked at seem to accept it as fact as well. They say all previous skills are carried. If not, then... hmm. Are you saying those trainer lists are wrong, or using unverified info, or is there something I'm missing? =) — HarshLanguage 18:52, 20 January 2007 (CST)

Our trainer info is in shambles because the people who are likely to add trainer info are the people who can't get the trainer info because of unlocks. Everything we have for non-Prophecies trainers is relatively dubious information. --Fyren 18:58, 20 January 2007 (CST)

Theres no real solution to this unless anet release a list or someone goes out and buys a new copy and adds them all. As long as there is one skill trainer that is correct, it should be enough, the earlier the skill trainer, the better. -- Xeon 22:47, 20 January 2007 (CST)

I had no idea there was that much doubt over how skill trainers worked! Is there any particular evidence that trainers don't work that way? Or is it just unverified, and tough to verify because of unlocks? — HarshLanguage 00:22, 21 January 2007 (CST)

[edit] need name for acq section

just realized the unlocks you get from acquiring a hero (default skill bar of heroes) are not listed on any skill pages, any one got a suggestion on what the section could be called. (Im referring to the Signet of Capture: Skill Trainers: sections under the acquisition section) -- Xeon 01:37, 21 January 2007 (CST)

Hmm. "Unlocked with Heroes"? "Hero Default Skills"? They're just unlocks, though, the unlocking character doesn't learn them... that's an important distinction. "Unlocked with Heroes (not learned)"? — HarshLanguage 21:13, 21 January 2007 (CST)

It could be "other" and contain all non-trainer/SoC methods. Perhaps create templates to keep the wording the same, like {{skill unlock profession|[[Switcher Name]] ([[Fooland]])}} and {{skill unlock hero|[[Dunkoro]]}}. --Fyren 21:26, 21 January 2007 (CST)

I'm just looking into the same thing. I'd simply call the section ... <drum roll> .... "Heroes" (doh)! I'll edit Mistrust as an example to look at. -- 02:42, 30 January 2007 (CST)

I don't think a section named "hero" with a hero name under it is very clear. --Fyren 02:44, 30 January 2007 (CST)

Hmmm ... the only difference I see to the other sections is that many people aren't aware that unlocking a hero will unlock all his skills along with it. Maybe if they read a heroes name in the "skill acquisition" section, that will make 'em wonder and they'll read up the details in hero or skill. -- 02:52, 30 January 2007 (CST)

Can i just add that the section is called acquisition and you are not really doing this through the heroes, you are just unlocking them, like someone mentioned above. -- Xeon 02:58, 30 January 2007 (CST)

Oh, is that so? Sorry, didn't read carefully. I was under the impression that the character learns the skill too. In that case I'd call the section "Heroes (unlock only)". (And I'll have to correct an edit that I made in Skill#Learning Skills). -- 03:03, 30 January 2007 (CST)

Buying a skill from a hero skill trainer teaches the skill to the character too. I've used this a few times to buy skills without using a skill point and platinum. Therefor we should list the hero skill trainers in the skill articles too. -- (talk) 18:25, 2 February 2007 (CST)

I think the hero skill trainers are all already listed in the relevant skill articles. The fact that the char learns the skill isn't 100% clear in-game either (it's mentioned, but the name itself is misleading). — HarshLanguage 18:58, 2 February 2007 (CST)

They are listed, someone went around and added them all in the first week of release. -- Xeon 20:25, 2 February 2007 (CST)

[edit] 0...12 vs. 0...15

As the wiki uses the old 0...12 in the skill descriptions and Anet uses 0...15 in update notes, we are getting lots of erraneous edits made to the wiki according to Anets update notes. Would it be better to use the same system as Anet? Or is the in game system still 0...12? -- (talk) 18:05, 2 February 2007 (CST)

ingame is still 0..12 AFAIK --FireFox 18:11, 2 February 2007 (CST)

Just checked, still 0...12 in game. The wording in game was the original reason for our using that as the range. (I'm not saying that we shouldn't re-think how we want to denote the range, I don't really have an opinion on it one way or the other.) --Rainith 18:14, 2 February 2007 (CST)

If the in game version is 0...12, then I vore for keeping it in use. It's a lot easier to check stuff in game if the wiki uses the same system. Someone really should contact Anet and ask them to keep the same system everywhere. -- (talk) 18:22, 2 February 2007 (CST)

I think that both 0...12 and 0...15 are unusual choices; the highest that an attribute can be is neither of 12 or 15. <LordBiro>/<Talk> 18:29, 2 February 2007 (CST)

I can understand where they both came from. The highest base level that can be reached without insignia, runes, reapons, etc is 12 so was likely the cap they conceptually wanted to show in-game; while 15 seems to be the level used by the game mechanics (much like we now use 0-15 for the parser add-on to automatically generate the values), so that's how the programmers view the skills and they likely write up the update notes. I would like to see consistency, although I doubt we'll ever see it. --- Barek (talk • contribs) - 18:36, 2 February 2007 (CST)

In game, when you unlock a skill and it pops up the little display with the skill name and description, it uses 0...12. When you mouseover the target monitor, you also see 0...12. This is why we chose 0...12 long, long ago. It was only afterwards ANet started using 0...15 in patch notes (August 2005) when we had already decided to use 0...12. Earlier patch notes didn't contain ranges.

I don't really care which we use. I could relatively easily switch us to 0...15 if people want. --Fyren 19:54, 2 February 2007 (CST)

I think we should keep the 0-12 range, as that's what people will see in-game. If we were to change it the problem with the update notices would be resolved, but we would be stuck with the oposite problem of people changing them to 1-12 as that's what the skill showed them in-game.

Ideally, ANet would change and be consistant, but I don't see that taking place. The next idea I see as a work around solution would be to find a way to use the parser function to auto-generate the range in skill descriptions (if possible) - but I'm concerned with the added complexity that would introduce to maintaining the articles. I think the only remaining viable option is to continue as we have been doing. --- Barek (talk • contribs) - 20:02, 2 February 2007 (CST)

I would prefer to see anet change their position on the way they supply their patch notes and change it to 0...12, it makes more sense considering through out the game they use the 0...12 system. Possibly a note should be put at the top of the game updates article to inform people that, they use 1...15 in their reports. -- Xeon 20:06, 2 February 2007 (CST)

That would probably take care most of the problem, but there are a lot of people unable to read even the most disturbing red 72 sized font. ;) -- (talk) 02:20, 3 February 2007 (CST)

True but it will minimize the amount of "mistake" edits done by the majority of people that are unaware of the different systems. -- Xeon 02:23, 3 February 2007 (CST)

Gah! Please, no more giant red fonts than necessary. My eyes still hurt from last weekend's update pages, I was so glad when the skills were reverted so I could remove those notes. --Rainith 02:25, 3 February 2007 (CST)

I didn't actually mean that we should add a giant red font. :D A normal sized one is perfectly okay, I hate big and disturbing notices too. -- (talk) 02:49, 3 February 2007 (CST)

[edit] Acquisition: "...only during quest..."

I would like to see that extra little bit of info when I look at the elite skill pages and check which bosses they can be capped from. Basically, when a boss only appears during a certain quest (not mission), such as A Land of Heroes, the skill page would say too. Reaper's Mark, for example, lists Midshipman Beraidun to be in the Cliffs of Dohjok, but only through clicking the link to Beraidun does one find that he is not there 99% of the time. If the skill page said that he was only available during that quest, then it would save users having to click on the wrong boss to get the skill from (if indeed they even do so, since my wife never did when she was checking skill pages. She would just go to the area and cap the elite while mapping). As for pages going out of date/innacurate when ANet makes changes... well, that's what the community is for! Jarus 06:15, 22 February 2007 (CST)

If I had to pick between having users click a link and having info that wouldn't get updated, I'd pick the link. I'm sure that we still have info that's been out of date since Factions was released. From my perspective, the community is never both thorough and timely. --Fyren 13:54, 22 February 2007 (CST)

Under that reasoning, should not NPC and Monster information be subject to the same limitation as well, then? Marga Coast has quite a few, for example. Jarus 05:56, 23 February 2007 (CST)

Obviously some info has to be duplicated but I'm trying to keep it to a minimum. --Fyren 12:24, 23 February 2007 (CST)

I also agree with Jarus, I feel it would be helpful to the public to have this information listed on the skill page. Often when capping, i will open the boss page and briefly glance at the map, but not much else. I'm pretty sure im not the only one in this regard and as such i believe that i can only help the community to have this on the skill page as well. -- (talk) 01:29, 25 February 2007 (CST)

I tried removing the extra info in a couple of pages, namely Forum Highlands and Vehtendi Valley, but someone put them back. It does seem that people do want it. Jarus 04:03, 2 March 2007 (CST)

Other types of articles, such as locations, have their own S&F. --Fyren 04:11, 2 March 2007 (CST)

Location S&F must include whether a boss is present only during a certain quest or not, but elite skill must not? Wouldn't that info be outdated as well if changes took place? (meanwhile, I'm re-reverting edits I made). Jarus 04:50, 2 March 2007 (CST)

While I'd vaguely prefer other articles be the same, I don't really look into any that aren't about skills or game mechanics beyond chacking for vandalism. --Fyren 15:59, 2 March 2007 (CST)

Fyren, would you feel any differently about a shorter, neater way of marking quest-only bosses? Even something as simple as (Quest Name) next to the boss name. I have to say, the only reason I don't feel more strongly in agreement with putting the quest notation on skill pages is that I'm already used to checking each boss page separately. Which is a hassle, but one I know is unavoidable under the current S&F. Ultimately, I think it should be there. — HarshLanguage 08:29, 2 March 2007 (CST)

Since enough people have brought it up this time, sure, go ahead and change the S&F article to say to do it that way (or some other way). --Fyren 15:59, 2 March 2007 (CST)

OK, I propose the following be added to the "Acquisition" section of the S&F:

If a boss is only spawned while a particular quest is in progress, add the name of the quest next to the boss name, in the format "(during quest Quest Name)" with the quest name linked to the appropriate page, as in the following example:

'''Signet of Capture:'''
*[[Commander Sehden]] ([[Bahdok Caverns]])
*[[Midshipman Beraidun]] ([[Cliffs of Dohjok]]) (during quest [[A Land of Heroes]])

Please suggest improvements to this proposal. Thanks. — HarshLanguage 22:56, 4 March 2007 (CST)

Seeing no opposition or suggestions about this, I'm going to go ahead and add it to the S&F tomorrow. — HarshLanguage 20:30, 11 March 2007 (CDT)

Added. — HarshLanguage 23:31, 12 March 2007 (CDT)

[edit] acquisition subsections order

First of all, there is incosistency between main article and the example. Article says "...switching sec professions, quests, trainers, bosses - in that order". Then example: quests, trainers, bosses, prof changers. I think that example is correct.

Second thing: still missing Hero Skill Trainers section, although already used in many articles. I propose placing it right after Skill Trainers. I'm writing this, because when tidying up skill acquisitions I came across Lightning Orb, where Hero Trainers are first and I'm not sure if I'm authorized to change this. /Redruid 10:05, 11 March 2007 (CDT)

I think, in most articles, hero trainers are after the normal trainers. The profession changers, from what I recall, aren't even noted in the same manner let alone the same order. Feel free to adjust the S&F article to be consistent and skill articles to match it. I don't have a preference for where the profession changers should be placed. --Fyren 11:42, 11 March 2007 (CDT)

Quests / Trainers / Profession Switchers / Bosses / Hero Skill Trainers seems like a good order to me. Though profession switchers might currently be after bosses; it doesn't really matter, either would be fine. I'd suggest whichever takes less work to implement. =) I've seen some of the skill articles with HSTs at the top, and it always strikes me as odd, so I agree it should be formalized. — HarshLanguage 20:28, 11 March 2007 (CDT)

Article changed. I think placing together both skill trainers is easier to read. Beside that it is already used this way in many articles. Changes to skill articles will be introduced progressively ;) /Redruid 12:05, 12 March 2007 (CDT)

[edit] ULC related skills

All article pages use (Elite) and (Duplicate). Doesn't make much sense for the style guide to be different. -- Xeon 18:37, 21 March 2007 (CDT)

It doesn't make sense for them to be uppercase. S&F guides exist to prescribe how to write articles. --Fyren 21:03, 21 March 2007 (CDT)

Write a bot and change them all, its the only way the wiki will be able to stay on top of the UC usage. Otherwise every article will follow the current trend of using the UC because thats how they all the articles are done and people wont refer to this S&F when they are making related skills, they will look for examples from other articles. -- Xeon 04:20, 22 March 2007 (CDT)

I like the lowercase, and consistency is always good, but I don't think it's worth the time and effort to go through the articles just to change the case. Even if it's done by bot, because that means it would be mainly Fyren's time and effort. — HarshLanguage 04:41, 22 March 2007 (CDT)

Which is my point :) -- Xeon 04:42, 22 March 2007 (CDT)

Introduced a bold text line to emphasize that it needs to be changed, this creates a long term solutions for this problem. -- Xeon 07:40, 22 March 2007 (CDT)

Hope you don't mind, Xeon, but I fixed the example table (it had a duplicate column) and reworded your note for clarity. I also didn't think the entire line should be bolded; it didn't match the style of the rest of the article and seemed to be unduly attention-grabbing. Anyone looking for how to edit Related skills will still definitely see it and know about the ULC change. — HarshLanguage 07:49, 22 March 2007 (CDT)

Ya, its worded much better now, was killing Varesh at the same time of writing heh, im doing duplicates in a few minutes. Thanks for that. 07:54, 22 March 2007 (CDT)

[edit] More on acquisition

I wanted to do an update on the Factions skill trainers page. While I was checking I noticed that the whole "skill trainers offer the same skills as the previous trainer" - statement is not true. I know other people noticed it as well but it never got corrected. Another problem is that the S&F page says you should list all skill trainers, not just the first one you'll likely encounter in-game. Before I read this page I changed some Warrior skill pages (like Lacerating Chop → placed a link to the Factions skill trainer list under "Acquisition", but you can place that link on each and every skill page...Once (if?) the skill trainers page is trustworthy enough it'll be better than listing 25 skill trainers imo. Any more thoughts on this, or are we just going to leave it this way ? --Erszebet 07:42, 9 April 2007 (CDT)

A LONG time ago I started a project that explicitly tried to verify the skills each trainer has, it's on each of the Skill trainer's talk page. It's quite a difficult task, and I only worked on the initial areas (up to Kaineng City). Maybe you can continue it? For an example, see Talk:Xu Fengxia. If my memory does not fail me, for a few trainers they do offer all the Factions skills the previous trainers offer, and the project was supposed to explicitly verify all of them instead of just making assumptions. -PanSola 07:57, 9 April 2007 (CDT)

Erszebet already is continuing it. --Fyren 08:33, 9 April 2007 (CDT)

Go ahead and do whatever you think makes sense and change the style guide accordingly. I'm not much of a fan of listing trainers as "teaching all skills except these," I think it'd be better to just copy and paste the list and edit it, though that doesn't have to do with the skills S&F. --Fyren 08:33, 9 April 2007 (CDT)

PanSola: You're partially right; up to Michiko the skills offered are cummulative. After that you'll see 2 or 3 'skill list patterns' - can't think of a better way to say it. AFAIK there're a handful skills of each prof. that aren't teached by all the trainers. I still need to sync those talk pages with the actual article. I used the talk pages as a starting point anyway. But it's kinda hard to know which one has the most accurate data. Take Cry of Frustration (no pun intended) on Xu's page for example: it's listed in his table on the article, but according to the talk page it's yet to be confirmed.

I'm gonna try to collect all the data I can first (still need those Luxon trainers) and update the trainer pages. --Erszebet 16:22, 9 April 2007 (CDT)

I'd say it's safe to consider the talk page data as accurate, even if it is overly conservative. Anyone who bothered to edit the talk page data probably know what they were doing, whereas those who edited the trainer page directly may or may not. With a situation like this, it's safer to be on the conservative side. -PanSola 17:59, 9 April 2007 (CDT)

I changed the S&F guide to list only the first trainer where you can buy the skill. AFAIK that's how it's been done mostly. I must also correct myself: the "skill trainers offer..."-statement should be true for Nightfall campaign, not for Factions (which has at least 1 bugged trainer: Vernados). --Erszebet 10:11, 13 April 2007 (CDT)

Has it been fully validated for Core skills as well? Their nature makes it very hard to completely confirm. -PanSola 10:53, 13 April 2007 (CDT)

Well you can never be 100% sure I guess. That'd require confirmation of each and every skill in the game (maybe...some day... :p ). We know that there're a handful of skills in Factions that can first be bought at Michiko, but don't appear on skill trainers lists further in-game. Examples are: Warrior's Cunning (W core) and Life (Rt - Factions-only). I didn't notice the same thing happening in NF, whether it be core or NF-skills only. --Erszebet 06:02, 14 April 2007 (CDT)

It wouldn't surprise me if Factions skill trainers and Nightfall skill trainers work differently. By considering Vernados as "bugged", you are setting up an expectation of Factions trainers using what you postulate for Nightfall as the norm. I feel rather uncomfortable with that. Because of known existence of cases where the "later trainer teach all from prev trainer" in Factions, we should be extra careful about making assumptions of any post-Kaineng trainer in Factions. (and Kaineng is special because it marks where the game progress expects the players to be reaching level 20). To assume Vernados is bugged sets up a prejudice against the possibility that every/most post-Kaineng trainers in Factions might have one or two skills that only they offer. A prejudice in a situation where the facts are already hard to verify makes it even less likely that we will have someone who ended up making the verification either proving or disproving the hypothesis. -PanSola 09:13, 14 April 2007 (CDT)

Ok, you're losing me. Have you looked at Vernados ? He only "offers" unlocked and known skills, no locked or new skills whatsoever. In all of Tyria, Cantha and Elona he's the only trainer to do that, that's why I said he's bugged. --Erszebet 09:21, 14 April 2007 (CDT)

Something that's been considered before (I can't remember if it was ever actually in the S&F or not) was that foreign characters aren't going to want to trudge backwards into newbieland to get a skill if it's available sooner for them. So, I amended the critera for when to list trainers to "all trainers before Michiko and Tohn, the first trainer at Michiko and Tohn and after." (I also shortened the "during quest" verbiage for captures.) --Fyren 01:51, 28 April 2007 (CDT)