GuildWiki talk:Style and formatting/Skills

Old stuff is in the archive.

Skill Formatting Example
As I went through the skills as per the discussion in GuildWiki_talk:Peer_review there were some common problems with the skill articles.
 * Ranges weren't bold (all fixed [user:Ollj|Ollj])
 * Ranges only had two periods (all fixed [user:Ollj|Ollj])
 * Misformatted acquisition section
 * Irregularity with bolding the article name (all fixed (no more boldnesses) [user:Ollj|Ollj])
 * Irregularity with denoting exhaustion, penetration, and elite status (working on it [user:Ollj|Ollj])
 * Missing "(Elite)" in the template for elites (?) (working on it [user:Ollj|Ollj])
 * Missing elite skills category for elites (working on it [user:Ollj|Ollj])
 * Fractions not using sup and sub
 * Missing no attribute category for some skills (all fixed [user:Ollj|Ollj])

The first two are easy, no debate there I presume. The next I give an example of what I think is a good way (and somewhat common way, from looking at most of the skill articles) of listing the three ways to acquire skills in GuildWiki talk:Style & Formatting/Skills/Everything Example. For bolding the article name, in the main style page, it's suggested you bold the article name only the first time it's used. For denoting the various things, I suggest what's in the example but I don't think it was ever discussed. For the last point, I don't think it was ever discussed but I like it.

Please mess with the example as you see fit before we start taking things out of peer review. --Fyren 03:42, 9 Jul 2005 (EST)

Good work Fyren! I like it a lot :) It's a good way to be able to talk about the format of articles! Points of interest: 07:18, 9 Jul 2005 (EST)
 * Article names should always be linked rather than bolded, even if they are referencing their own article. MediaWiki recognises the link and renders it as bolded text. This was decided upon some time ago (I was unwaware that MediaWiki did this at first, until Tanaric pointed it out) as the content produced is more useful when referenced from elsewhere, i.e. if an article is Included elsewhere, the link will not be rendered as bold and will point back to the included article, which is desirable! :)
 * Although I disagree with it, Template:Skill begin is included in the Skills category, meaning any page that contains the skill box is automatically included in the skills category. While this is a labour saver it means that a few example pages are included in Category:Skills :/
 * I don't agree with the use of the "spells" category, or of "enchantment spell" or whatever other categories are used to group skills by their type. Firstly, all instances of these category names are singular, whereas other category names on the site are typically plural, (save for the "contains xxx" categories, although thats reasonable) so I vote the category names are changed if they must be kept. Secondly I think they are pretty useless. I'm always wanting to find out what kind of skills I have and what I need by looking through the categories and I've never used this method of browsing. If a number of people do then obviously this is just me :)
 * Probably not the right place to say this but Elite redirects to Elite Skill and is pretty pointless... :/
 * "Skill" means all skills of the type "skill". "Skills" means all 456 skills together. The "skills category" must be plural, its different from the "skill category" that only lists "skills" of the type "skill". everything else should be singular. [User:Ollj|Ollj]

My point about the bold/linking was sometimes it's not linked at all and sometimes it's always linked. I think categories for skill types can be useful, but I guess they should be singular. (I also suggested that 'contains whatever' should be 'yields ' so things don't complain piles of dust, as was complained.) If you wanted to make a build around ether renewal, you might look through all the enchantments to see which profession you want to choose to pair of E.  The elite link is just there to mark in the template that the skill is elite. Is there a better way to do this? --Fyren 11:26, 9 Jul 2005 (EST)


 * Yeah, I was just over-clarifying really Fyren :) I'm prone to doing that, hehe. Well if you think they are useful then I'll concede that skill type categories are ok. But I still think we should refer to just like we do to  and  etc. I like the elite link as it is, although it shouldn't redirect :) 21:17, 9 Jul 2005 (EST)


 * I agree with you in principle, but there is a practical problem with Skills. Bear with me here. There are skills and Skills. "skills" represent the general idea of things you put on your skill bar. "Skills" are skills that begin with the in-game text "Skill.". If we go with pluralized categories, then Category:Skills will conflict with Category:skills. See what I mean?

>>"skills" gone to "category skills" "Skills" gone to category "Skill" [User:Ollj|Ollj]


 * I think we should make categories based only on sortable criteria in-game. Thus, Enchantments would be valid, since you can sort your skill list by type and get an enchantments header.  However, does a "skills" header ever appear?  If not, the category is not useful, and the point is moot.  &mdash;Tanaric 15:24, 13 Jul 2005 (EST)
 * Theres skills that target skills, so category is usefull. [User:Ollj|Ollj]


 * Just checked, and Charm Animal, Comfort Animal and Troll Unguent are "Skills". This puts us in a difficult position, since it means we cannot look for these skills through their type like we can with skills that are enchantments or spells etc. Unless we can come up with a different way of referencing something. I would not like to see changed, because it would be a lot of hard work, and more importantly because it is a category of skills, and any other name would be confusing. Any suggestions are welcome (although I suggest we perhaps start a new section for this discussion to avoid confusion)  22:51, 13 Jul 2005 (EST)


 * Lots of skills are of type "Skill". Expertise specifically triggers off of Skills not Spells. Also, many of the interrupts will specify Spell or "action". A Skill would not be interrupted by a Spell interrupt. This is why I have been putting the Skills into . Every skill has an official type. It is the the first sentence of the in-game skill description. (Which we put in , but omit from ==Description== for brevity.)

This Everything Example is very handy. There are a few changes I would like to make. I will modify the example page so everyone can see what I mean.
 * I think the Acquisition section should be ordered by cost, Quest (free), Capture (half price) and Trainer (full price). We could order by location, but one could argue over the correct ordering of locations since you can skip ahead of the missions.
 * Hyperlinking "Signet of Capture" kind of breaks the formatting of Acquisitions. I think it should just be "Capture".
 * I'm changing the casting time to 3/4 so we can argue over "3/4", "&#190;" and "3/4".
 * You're right that there should be an order for acquisition, whatever it might be. I'm not sure how linking the signet breaks formatting, could you explain?  And the decided format for fractions was the last of your three, though I guess it doesn't really matter as long as we're consistent.  I like the last one the most.  --Fyren 10:25, 14 Jul 2005 (EST)


 * "Quest" and "Trainer" aren't linked, so it seems inconsistent to link "Capture". We could link all three I suppose, but I am opposed to that. If we need to explain the meaning of something we should do that in a single article, e.g. Skill Articles Explained and make a link to that at the top of every skill via the macro. Then we can do a full write-up explaining the terms (like Capture) for all of the skills in one place instead of having to maintain 200+ skill articles.


 * I vote for &amp;#190;, as it's semantically correct. &mdash;Tanaric 20:09, 14 Jul 2005 (EST)


 * Well I think this kind of thing could be discussed in Skill details since it already exists. Although perhaps this is the wrong place. Help:Skills might be another good option. I'm torn between &amp;#190; and 3/4, while the first is technically correct the second is much easier to edit, and much easier to read if you are just looking at the wiki code. As far as semantics goes I think anyone getting hold of the html of the page would understand 3/4 means &#190;, but I'm not entirely convinced which is best. Hehe :) {User:LordBiro/Sig}} 20:15, 14 Jul 2005 (EST)


 * How about we make a set of macros, , and use that. Then they will all look the same, and we can change the formatting in the future if we decide to do it differently.


 * Biro, I agree with your last sentence, but it really doesn't apply. 3/4 is fine, semantically, but 3/4 is not.  Fractions are not written in superscript or subscript, but a special format all of their own.  Furthermore, maybe I just read too much math, but 3/4 just doesn't look like a fraction to me. Since it's not quite a fraction, it's jarring.  At least 3/4 is commonly understood to be fractional form.  Alternatively, we could just call it 0.75, and avoid the problem entirely.  &mdash;Tanaric 22:09, 14 Jul 2005 (EST)


 * You think 3/4 doesn't look like a fraction but Â¾ does? Will the latter display properly on all systems?  --Fyren 04:22, 15 Jul 2005 (EST)




 * Yes Fyren, I believe that &amp;#190; will display correctly on all browsers, or should do at least. In fact it is 3/4 that is less likely to display properly, as shown in my example using lynx on linux. Tanaric's suggestion of using a template to describe fractions is a good one. We could even use Template:1/4, Template:1/2 and Template:3/4 if everyone is ok with it. I realise that slashes suggest a sub page, so this might not be the best solution, but I don't know of any disadvantage to using a slash in an article title. It's not like creating a namespace, afaik. Someone with more knowledge on this subject could perhaps give some input? If this is not ideal then I think Template:One_quarter, Template:One_half, Template:Three_quarters etc. would be easiest to understand. 07:36, 15 Jul 2005 (EST)


 * Actually, some random unsigned guy talked about Templates. I think it adds needless complication to something that's really not a problem.  " 3/4 " is an HTML kludge that shouldn't even be considered, as the lynx screenshot proves.  However, because the syntax for &amp;#190; isn't immediately obvious, I think 3/4 is fair.  'course, I still think 0.75 makes it easier&mdash;doesn't quite jibe with the game, but I think mathematical equivalency is okay&mdash;and it avoids a damned silly argument about fraction syntax.  It should, perhaps, be noted that the game itself uses &amp;#190; to display fractions. &mdash;Tanaric 15:42, 22 Jul 2005 (EST)


 * Well forgive me for introducing the "kludge" into our skills formatting. The wiki was still new at that time, and i was fully aware of what i was doing, though i don't remember anyone bothering to suggest anything better back then. "3/4" in no way looks like what it does in the game, Â¾ wouldn't necessarily appear properly on a web browser rendering with a different character encoding(or font), and our wiki doesn't have the maths plugin installed(the one wikipedia uses). I was(and still am) quite sure that any web browser since mosaic would know what to do with the super and subscript tags, and it seemed like the best workaround at that time; i scripted something that would automatically generate codes for the skill tables, and i had to decide on an approach that would work best(notice how all the monk skills already have their skill tables; some mistakes here and there, but they got fixed quick). honestly, i don't see how a text-based web browser not being able to render said tags make it any less likely for users to see the "kludge" properly. if we used the wiki-maths to do fractions, it'd generate images that lynx wouldn't be able to display anyway. are we gonna settle for 3/4 just because of one text-based web browser? Nuble 07:41, 29 Jul 2005 (EST)


 * Â¾ might not, but &#190;(&amp;#190;) should work for any browser, see the wiki code and the source for the page to see why these are different characters. You made a reasonable decision Nuble, but I think we should settle for &#190;, not because it renders nicely in lynx, but because it's correct. Also, what to people think about the use of templates to display fractions? This way if we change our mind in the future it will be a much less painful process to alter. 08:25, 30 Jul 2005 (EST)


 * i was just about to say that if we're to evaluate our pages based on how lynx renders it, might as well use ascii art to replace the skill images since, well, lynx only renders ascii text, but that'd just bring up more unnecessary arguments. anyway, templates will definitely solve a lot of our problems, what's with the different 1/4 and 3/4 and x...y's we have floating around. i say go for it. i'll do my part editing the skill pages as needed later. Nuble 03:02, 1 Aug 2005 (EST)

I propose we change the example article, specifically to change "Usage Notes" to simply "Notes", because there might be more to say about a skill than just how and when to use it. Alternatively we could add a new paragraph, although that seems pointless when we already have such a closely related one.
 * Sounds good. I just put "usage notes" in since it was used in a lot of existing skills.  --Fyren 20:04, 22 Jul 2005 (EST)


 * Could we move GuildWiki talk:Style & Formatting/Skills/Everything Example to Style and formatting/Skills/Everything Example? Just that since the case crusade the parent article has changed, and it was initially created underneath this talk page, when really I think it should have been created underneath the Skills formatting article. :) 21:29, 22 Jul 2005 (EST)

I have an idea how to simplify inserting the fractions into an article. Just extend the Javascript bar at the top of the edit box to include the Unicode characters: Roland of Gilead 05:03, 5 Aug 2005 (EST)

Woah, sorry, forgot about this discussion. Nuble, no offense was meant to you: however, this is a wiki, and it evolves. Part of that evolution is making everything more correct, and that's what I'm trying to achieve here. Anyway, I agree with Roland about adding them to the JScript bar. I add further that the onSubmit replace script (you know, the one that replaces ~ with names and dates) be extended to automatically convert fractions into HTML entities and -- into &amp;mdash;. Just a thought; I can think of plenty reasons NOT to as well, but I'll leave those to you to argue against me. :) &mdash;Tanaric 05:17, 5 Aug 2005 (EST)


 * Putting the arguments for and against altering the "onSubmit" functionality of MediaWiki to one side for the moment, it will be much easier to implement a change to the JScript bar than to the "onSubmit" function. With this out of the way we could move at least one small step closer to better syntax. 10:28, 5 Aug 2005 (EST)

Attribute Point to Skill Value tables
Please note: I have uploaded a small java program to create simple skill tables that relates the linked attribute to the skill's effect(s). Look here for the code.


 * I'm not very pleased with the current attribute tables, although I do like the idea of having such information. The syntax of the table produced is incorrect (or if the blank row is intentional it's not very pretty ;)), but my main problem with them is that the information is not displayed very elegantly as in the case of Mark of Rodgort. I have been thinking about this problem, and I don't really know how we can display this information without using a table in some way. I had wondered about the use of a javascript attribute point to skill value calculator, but I'm not sure if this is a good idea.
 * Also, do the values really rise in such a linear manner after AP 12? I had read that they did not. 09:59, 22 Jul 2005 (EST)


 * Theres a BIG problem with this, everyone is rounding a linear graph from 0 to 12 (and it stays linear till 20) BUT guild-Wars too often does NOT round logically for some higher reason i can not see yet. So you can not calculate it, you need a database.
 * I have actually tested every skill that I have added, up to at least level 17, and contrary to what you may have read elsewhere, it DOES scale linearly even after 12. Give me a counterexample if you know one. Or just try it yourself for any random skill with +armor & sup Rune. Write down the absolute increase for every level from 0 to your max, then try to find a regular pattern in the increase values. If you find a pattern that matches all values, it's linear all the way.
 * OR you just trust me when I say: Every Skill variable, if plotted against attribute level, looks like a simple linear graph that is offset in y-direction by some base value; I have tested enough skills to say this with confidence. Roland of Gilead 11:52, 28 Jul 2005 (EST)
 * Never sayd its not linear, I just say your tables round correctly while guild wars does not round like you do!

Use this Template?:

Example1:

Example2:

variables: - name = name of the line - s   = font size of the line [html] - w1  = width of the name box - w2  = widths of the number boxes Used Templates: - nrow20     = line showing the numbers from 0 to 20 to make a line title - -24...-14  = lines storing and showing green number variables for each range -- nrow start = table start -- nrow end  = table end -- nrow      = one box element with a border and centered text

you can klick the x to get to the template to change any number. I actually like how voids display, better than "0" or "-"

many skills suse the same ranges, so a template is good!


 * I think we all agree there should be a table in the skill pages but I don't think this table/template yet achieves it in a good way. I'm leaning towards just a plain table with only templates like Ollj's nrow20, start, and end, and one more that will take the actual values for a row, not something like  .  --Fyren 04:27, 2 Aug 2005 (EST)


 * I'm very glad you are discussing this Ollj :) The templates here are good, but I can't help but think they are still too complex. Can anyone provide some proof (screenshots or something?) that the values do or do not scale linearly in any given case? I haven't tested this myself and so I'm unsure. 08:15, 2 Aug 2005 (EST)


 * One simple recommendation: It would make sense to me if the "x" link actually said "edit". It might not be clear to new contributors exactly what the "x" is for. 08:18, 2 Aug 2005 (EST)


 * This is simple: if you dont (want to) know what the x is for you propably should not edit, if you want to edit you know how to anyways. / "x" was chosen because it can be only 2-3 digits long anyways, want it to be "set"? - and its a template because a lot of skills use the same ranges!
 * I think I'd prefer it to be outside of the table. I'm someone who would edit them if I had info to put in, but I wouldn't know what the "x" did till I moused over it to see.  And then I'd see it took me to the template, not to edit the template.  Perhaps another template just to add a small line of text that says "click here to edit" under the table?  --Fyren 01:44, 9 Aug 2005 (EST)

These tables do not display correctly in Firefox. &mdash;Tanaric 16:27, 9 Aug 2005 (EST)


 * They do for me. Ugly, either way, though. --Talrath Stormcrush 16:34, 9 Aug 2005 (EST)
 * Ugly is easily fixed. They display correctly in my Firefox, also.  --Fyren 16:38, 9 Aug 2005 (EST)
 * I mean, correctly, as compared to how they display in IE6. Compare the two, and you'll probably agree that Firefox's is less-desirable.  &mdash;Tanaric 17:10, 9 Aug 2005 (EST)


 * It renders pretty much the same for me, but the syntax is awful. Every cell contains a table, I don't know why. 21:03, 9 Aug 2005 (EST)
 * Because I wanted fixed width for each cell that is still variable, and all that with wiki code. - If it doesnt render the same way with all browsers you should try to fix that.
 * Strange. In Fx here, the empty cells render with no width, whereas in IE they render with the same width as the column headers. &mdash;Tanaric 23:22, 9 Aug 2005 (EST)
 * Im my FF, they are fixed width. --Fyren 03:21, 10 Aug 2005 (EST)


 * Okay then, I'll shut up about it. However, since I'm pedantic, I'll mention that the official abbreviation for "Firefox" is "Fx". :) &mdash;Tanaric 18:44, 10 Aug 2005 (EST)

Lots of Things
There's way too much discussion to move here and I'm not sure how to deal with it. I'll try to point out the main pages: --Fyren 17:06, 9 Aug 2005 (EST)
 * Talk:Skill Template Guide: There's a lot of issues there people need to either say "I like it," "that's a bad idea," or "you should do it like this..."  Almost every issue on the page is unresolved to some degree.
 * Talk:Elite skills list: Discussion on formatting the page with a list of all elite skills, though it's mostly taken care of.  Addition input would be nice.
 * Talk:Skill: Discussion on denoting eliteness for skills.

Categories
Okay, my above section didn't get much input on the topics. So, I present, in the proper location for discussion, categories! Right now, we've got Category:Fire Damage and so on for things that deal that type of damage. Ollj suggested a while ago that we have Category:Causes Poison and so on. Besides conditions, we could have knockdown and exhaustion. Other categories that might be useful are removes enchantments, removes hexes, removes conditions, snares, buffs speed, buffs elusion (to cover block, evade, dodge without using those words), reduces damage, and buffs armor. I've always wanted to be able to crossreference some of these things, like "what are all the ways to cause ," and I'm sure others have wanted this as well.

Another suggestion I have is we add things to the category with the profession in the name, as in. This would help searches like I mentioned above, since you might only want to find all ways to do something only for the two professions for one of your characters.

So, what does everyone think? What other categories might there be of use? (The category suggestions above are just off the top of my head, I'm sure there are others.) I think this is all good, I'd be fine doing it all myself if no one opposes such changes. --Fyren 03:26, 11 Aug 2005 (EST)


 * Okay, then. I assume everyone's all for it!  I'll get right on it!  I also thought up the categories causes cantaloupe, eats babies, and buffs shepherds!  I'll get right on adding them unless someone speaks up.  --Fyren 04:01, 13 Aug 2005 (EST)


 * lol, hey :) Well, I don't disagree with more categories necessarily, but the ones we have are a mess. I really hate the fact that Necromancer General/Monk General etc. exist for skills with no attribute. It's just not a very good name! And the fact that some categories use plural and some use singular still annoys me, even after the discussion about the difference between skills and the skill type "skill"... So yeah, I also don't think a category is necessary for "causes exhaustion", since only 1 skill does. 21:11, 13 Aug 2005 (EST)


 * I'd probably change the "general" ones into " Unlinked Skills" or just " Unlinked." My overall goal is to do a pass through all the skills to do lots of things at once.  I'd change them all to plural, except the "skill" thing, which I guess can use a little more discussion.  For exhaustion, I meant the ones that are self-imposed.  --Fyren 03:24, 14 Aug 2005 (EST)

Here are the new categories I've come up with: These seem to cover various effects that aren't specific to just a few skills.
 * Causes [each condition, Exhaustion, Health/Energy Re/Degen]
 * Knocks Down
 * Removes [Conditions, Hexes, Enchantments]
 * Buffs [Speed, Armor, "Elusion" or whatever, Attack Speed] (maybe "improves" instead?)
 * Debuffs [same as above] (degrades? worsens?)
 * Interrupts
 * Drains Energy
 * Generates Energy
 * Requires Corpse (uses corpse?)
 * Heals
 * Increases Maximum Health
 * Questable
 * Not Questable

To note, here are the categories that we're using already:
 * Skills
 * Elite Skills
 * [Class] Skills
 * [Skill Type]s
 * [Attribute] or [Class] General
 * [Damage Type] Damage

Some issues with the existing categories:
 * Attributes and damage categories like "Air Magic" and "Fire Damage" don't fit the general pattern of categories being plural noun phrases or verb phrases, I suggest Air Magic Skills and Deals Fire Damage
 * "Mesmer General" is a poor name, I suggest "Mesmer Unlinked Skills"
 * Some aren't plural, like "Stance," I'll fix the singular categories
 * The skill type "skill," I don't know what to do about this (Ollj brought it up but no one commented)

The last point refers to the fact that we have a Category:Skills that contains all skills, but "skill" is also a type of skill. I don't know how to fix the name conflict. "Skill" and "Skill (Skill Type)" or "Skill (Type)" seems like a poor solution.

No one's commented besides Biro. I'm going to wait a couple days for discussion here, then lay out my proposal for AoE, targetting, and "method" of execution, and after that has been discussed (or hasn't) I'll go through all the skills myself to implement all this stuff. --Fyren 09:29, 19 Aug 2005 (EST)

You could get some "Requires [a condition]" pages although some of those would be short. For example Gash requires bleeding. "Causes Exhaustion" seems kind of silly - why would you want to look up those skills? The Exhausted Elementalist Comedy Build? Also, this is another place where those short skill description templates could be helpful.--Cloak of Letters 08:59, 20 Aug 2005 (EST)


 * I think "requires " would be too small. Glyph of Energy removes exhaustion from your next spell, so it might be nice to be able to list them.  It is pretty specific, so it's not a big deal if "causes exhaustion" is scrapped.  How would the short listings help?  --Fyren 09:25, 20 Aug 2005 (EST)


 * I'd rather have a list of skills on these pages instead of a list of skill names to open in new windows.--Cloak of Letters 10:19, 20 Aug 2005 (EST)
 * I guess we just disagree there. While I like the reference page, I don't like the "short" pages/templates.  Categories, though, just need a one-liner ("this category contains all the skills that cause bleeding") and  and such on the skill.  I'd rather do that than maintain a page.  --Fyren 10:31, 20 Aug 2005 (EST)

Unless someone disagrees soon, I'm going through the skills and adding the above categories, except maybe the exhaustion one. Then I'm going to write a Perl script that crossreferences them, and if that turns out well, I'll see about getting it hosted on this server. --Fyren 02:54, 12 Sep 2005 (EST)

After some thought, I have to disagree with adding these new categories. I think it would be better to just have those skill listings appear in the relevant article instead (i.e. poison-causing skills as a list in the poison article). It would provide more usefulness without the rather excessive category clutter. For example, I find the list of "Skills that cause fire damage" under Fire damage more useful (due to organization by profession) than Category:Fire Damage (which is also ambiguously named...why does Mantra of Flame not belong?). --64.186.172.227 04:20, 15 Sep 2005 (EST)


 * Some of the effects don't have articles. If we add links to the articles that do exist, we're doing work that the wiki can do for us.  About the "fire damage" category, I said it should be "deals fire damage" to fit in with our category naming scheme for everything.   For organizing things by profession, I wavered on it, but listing everything as  and so on would sort it by profession and then by skill name.  --Fyren 04:36, 15 Sep 2005 (EST)


 * I don't understand how the work would be substantially less in that case. Wouldn't it be "add  to a dozen articles" versus "add a dozen links to a corpse article"?  Actually, wouldn't the system of links in articles be less work just because a ton of those are done like that already (such all the conditions)?  --64.186.172.227 04:26, 16 Sep 2005 (EST)


 * "Deals fire damage" is much better, but I still slightly wince at that name because, with respect to article namespace, that should technically include Fiery Dragon Sword. Maybe a better example would be to ask which among Apply Poison, Fevered Dreams, and Martyr would go in , and why?  They all can induce the poison condition indirectly, but it's not immediately clear which would belong.  Keeping the list in the poison article allows for the flexibility to handle this sort of ambiguity. --64.186.172.227 04:26, 16 Sep 2005 (EST)


 * As far as the correct categorisation of articles goes I am for it. By this I mean that skills are organised by their attribute and profession. For everything else I would prefer lists. I realise that it's more hard work, but just because something can be grouped into a category doesn't mean it should. If a Beaver eats wood should "Beaver" be in the "eats wood" category? I realise that's a silly example, but I just want to explain my thinking. I am not entirely opposed to categories that group skills by certain properties, but I would prefer to see all articles in as few categories as possible, preferably one category. Sorry if I seem like I'm backtracking Fyren, I don't think I understood your intentions last time I posted. 06:28, 18 Sep 2005 (EST)

Regarding mesmer unlinked skills and the like, I suggest that those skills simply be the only ones directly under "Category:Mesmer Skills" (other mesmer skills will be members indirectly, through subcategories). For those skills, attributelessness will be implied by their appearance at that level instead of within the attribute subcategories. --67.169.184.133 00:01, 21 Sep 2005 (EST)

For a simple solution to the Skills vs Skill (Skill type) naming conflict, see my recent proposal in Talk:Skill (Skill type) --Rezyk 07:16, 22 Sep 2005 (EST)

Of ranges, tables, and templates
These have all been discussed a lot. I'd like to see where people stand since the discussions didn't seem to resolve. If there's markedly lopsided support for something, that's the way we should go. If there isn't... more discussion? I'd try to summarize the arguments for each, but I'm probably biased (since I can't think of arguments for some of them). I don't think there were any other options than what I list that were brought up and had support. Add choices if you think I've left out something.

Please edit and sign your name under the way you think is best. (Add " #~ " below your choice.) --Fyren 12:05, 14 Aug 2005 (EST)

'''Both votes are concluded, as Ollj is in the process of deleting both his range pages and templates. &mdash;Tanaric 00:16, 20 Aug 2005 (EST)''' Should the ranges in descriptions be linked (as in 1...3 or 1...3)?
 * No links
 * 1) Fyren 12:05, 14 Aug 2005 (EST)
 * 2) Tanaric 18:10, 15 Aug 2005 (EST)
 * 3) Crusty 08:25, 17 Aug 2005 (EST)
 * 4) Karlos 15:42, 17 Aug 2005 (EST)
 * Links
 * 1) Ollj
 * Either way
 * 1) kaarechr 01:25, 17 Aug 2005 (EST)

Should there be tables made from range templates skill number data (like Ollj has been doing) or tables from a single table template with numbers filled in per article? (Add a "no tables at all" option if wanted.)
 * Tables with range templates
 * 1) Ollj
 * Tables from a single template, data per article
 * 1) Fyren 12:05, 14 Aug 2005 (EST)
 * 2) Tanaric 18:10, 15 Aug 2005 (EST)
 * 3) kaarechr 01:25, 17 Aug 2005 (EST)
 * 4) Crusty 08:25, 17 Aug 2005 (EST)
 * 5) Karlos 15:42, 17 Aug 2005 (EST)


 * I'll assume it's too early to declare unanimous victory. --Fyren 10:31, 15 Aug 2005 (EST)
 * Let's wait until the weekend. No harm can come of it. &mdash;Tanaric 22:59, 16 Aug 2005 (EST)
 * Nice, but a democracy needs more than 3 people and is useless if most of its population is ignoring debates and votes. Ollj
 * once again some arguments:


 * 1) fixed width for each column.
 * 2) flexibility in size and width and title of each line.
 * 3) All tables and all ranges (but mending) seem to use the same numbers, thats why any new data should be stored in the template to show the same data for all skills.
 * 4) the template-data is easy to change (for a template) because it shows a link to itself.
 * 5) The template-data can also be used in "skill tumbnails", to use them in builds (goto discussion) or on the pages for each attribute.
 * 6) Green numbers are important for all "unspecialisated" builds (that have no attribute skill above 14). and specialisated builds [16 13 4] are neither always be best, nor the only builds to use and they should prever high increasing attributes, too.
 * 7) my table is just a table with a modular (more flexible) strcture. I tried a lot to make it just look like any other table, but i failed, till now. I finally killed the last bug in it, and this opens a way to change its look. Ollj
 * 8) I fixed the style! it just looks like a table now please test on all kinds of browsers, didnt use anything but "style="" . only disadvantage now is that empty spaces have no fixed width... working on that.Ollj
 * I didn't argue for my view. If you didn't say this on the other talk pages, you should have then.  I'm not going to remove your agument above, but I don't think it should be here.  --Fyren 05:02, 17 Aug 2005 (EST)
 * Oh nice, a vote for removal without own arguments while ignoring my arguments and pleaing do delete my arguments. thats stupid! whats your problem man? --Ollj 05:14, 17 Aug 2005 (EST)
 * Scroll up to "Lots of Things." Click the links.  See the pages of arguments.  I didn't want pages more here, since they achieved nothing first time.  --Fyren 05:17, 17 Aug 2005 (EST)
 * I read all the "lots of things" stuff. Its a lot of discussion, but it barely touches the green number ranges being wikified or not, they just got ignored. this proves the statement "These have all been discussed a lot." partically wrong (wikifiing wasnt discussed)! please quote/link some discussion about wikifiing ranges if you find any. you just sayd you didnt like most of the wikifications. all other discussion was about other wikifications and categorisation.--Ollj 06:15, 17 Aug 2005 (EST)
 * All green number ranges articles discussion is in Talk:Green_Numbers! --Ollj 06:15, 17 Aug 2005 (EST)
 * All actual discussion about range tables and wikified ranges is in "Attribute Point to Skill Value tables" above. LordBiro liked the information of the green number ranges, just wasnt sure about the style of the tables (wich improved a lot since then). Hewus added content to the ranges and started a discussion on 1...3. There Hewus wants a table on each site. And I proved that a template still makes sense. --Ollj 06:15, 17 Aug 2005 (EST) your only argument is still that you dont like them?
 * how about this: I agree that all the range articles are not THAT usefull yet. I thought I would find something special that would really make that pages usefull, but I just noticed that I already found it, and what I found can be presented in different ways, like on Divine_Favour + a templated table on each skill. (template if multiple skills use the same range.) For example I actually thought cross-linking between the ranges pages could make sense for some strategy guides, but while getting more data I just did not found a reason for that. The green number articles made sense to get all the data together, to link all the ranges to all the skills and to find out what skills use what ranges as quickly as possible. This answered a lot of my statistical and strategical questions and the question how big the role of the green numbers is in this game. I searched for a deeper meaning in them, for a link between one range to another, but didnt really find it. I didnt find as much "green number related"-links between the skills as I hoped to find. Just found links of green number ranges between skills of the same attribute!!! wikifiing the green number ranges and using a template for the range table (still) makes sense if another skill (of the same attribute) uses the same range, because those skills are still linked to each other by how their numbrs increase. That leaves the 8...18, 1...3, 1...8, 3...13, 1...16, 5...17, 5...24, 1...24, 1...32, 10...34, 5...41, 16...67, 20...68, 10...82, 7...91 ... range articles justified and others seem to lose justification. (i dont think they will add new skills anytime soon that might justify more range articles) --Ollj 07:11, 17 Aug 2005 (EST) Hey its 456 skills that share a lot of ranges with each other, and each range has ~19 variables in it, i just got overview over all that. The only problem is, I did not find as much as I thought I would find being worth to get overview over.

My 2c: Would be nice to have the table on the same page as the skill description so you can see all the information you need without having to print/refer to another page. Also its possible that a future GW update nerfs/changes a skill so it no longer complies with all the other skills in a green number range (not sure if this is possible - depends on how GW impliments things), in which case, having the data for the range in each skill article (as opposed to one article that all the relevant skills link to) would be more robust. It would take longer to do things this way, but hey you only have to enter then information once ;) PS full credit to Ollj, i think theyve done a superb job gathering all that info, i just think it would be more beneficial if it were formatted the way i explained --Crusty 08:25, 17 Aug 2005 (EST)


 * I agree. Nothing wrong with the information (it's great stuff, Ollj), but templating it just doesn't make sense.  They share the same ranges because of balance issues, but that doesn't mean those ranges won't change later, for balance issues.  I'm all for reduction of work, and I'm usually the first to modularize something to the point of absurdity, but... well, we're past the point of absurdity with these number range articles and the corrosponding templates.  You keep saying you've proven templates are good.  Where?  All I see is an extremely complicated, arcane syntax for tables that are pretty straightforward to create.  Templating these creates a significant barrier for new editors of skill pages.  Furthermore, the required kludges with wikicode syntax (unless something has changed) perverts the HTML of the page.  I can't imagine lynx, for example, being able to actually view your tables (and I intend to test that when I get home from work).


 * By your design pattern, Ollj, we should make different template for skills relying on Healing Prayers or Axe Mastery, since, after all, they share a common attribute. However, it makes a mess in the long run.  Templates are good for a whole lot of things, but data simply isn't one of them (at least, not on wiki).


 * &mdash;Tanaric 15:45, 17 Aug 2005 (EST)


 * I'll reiterate my suggestion which I made in some other talk page: Move the math to separate math pages. I believe there are people like Ollj who are into this stuff. I am not personally and am still waiting for the day that I find any of that info useful. Still, I think it is useful info to have around as long as it is accurate. My point is to keep it out of the main articles, like the Divine Favor article that Ollj is useing as an example. The reasons are:
 * To say that the table is cryptic is an understatement, especially with no headers. It is very hard to read.
 * It is empirical information, subject to change.
 * All we need to do is in the Divine Favor page just mention: "For more details on how Divine Favor affects all the linked skills, please consult the Divine Favor Increase Chart" or something like that. --Karlos 15:42, 17 Aug 2005 (EST)


 * I vehemently disagree with this suggestion. While the math data may be a bit arcane as presented (mostly due to problems with templating), it would be very easy to label and present properly.  It deserves its own section on the skill page, of course, but no reason to create more articles on essentially the same topic.  The fewer articles a user has to go through to reach his intended page, the better. &mdash;Tanaric 15:45, 17 Aug 2005 (EST)


 * Woah, he's got it in attribute articles now too? My above statement stands for the skill articles, but there's no reason at *all* for this stuff to be in attribute articles. &mdash;Tanaric 15:50, 17 Aug 2005 (EST)
 * Just because you dont understand that "stuff" doesnt mean there is no reason for it. Especially the attribute tables make it a lot easier to make any kind of build. --Ollj 17:37, 17 Aug 2005 (EST)


 * I understand the tables. I also know that they are hard to look at and even harder to decipher. I personally have not found a single use for all that data, but I do not deny it could be interesting. It's just not that important. Sorry if you don't feel the same way. We won't be able to reconcile that. --Karlos 21:10, 17 Aug 2005 (EST)
 * - Go to Divine Favour read the text bolow the table to understand it. Example: Divine Boon starts with 24 and for each divine favour more it ONLY adds 1 or 2 healing. Divine Healing starts with only 10 and gets 16 or 17 more healing for each attribute skill more. Now what skill you prefer with high divine favour and what skill do you prefer with low divine favour? THATS what its all about! --Ollj 22:08, 17 Aug 2005 (EST) of course you can still vote to delete this good info just because you dont get its meaning.
 * The answer, which you have overlooked in your overzealous analysis, is that you're looking in the wrong place. How often do people take divine healing?  Very rarely.  How often is boon used?  Fairly often.  It has nothing to do with your "relative increase" or how much the numbers change per point of divine favor, but that boon interacts well with protection monks but divine healing is basically heal area that heals some more but has an insane recharge.  --Fyren 04:55, 18 Aug 2005 (EST)
 * relative increase has nothing to do with how often a skill is used!!! and nothing with how good a skill is (because there is no such thing as a better skill)!!! It even ignores skill combinations (and shows some others)!!! Divine boon IS indeed nice for a lot of protection skills -> (less divine, more prot) just fine! The "insane" recharge of divine healing just LOVES quickening zephyr, like all long recharge skills do, this asks for other protection skills (less prot more divine). Im tired of repeating myself over and over, there come GREAT new builds when you care for relative increase. --Ollj 05:54, 18 Aug 2005 (EST)


 * so im clear, realtive increase is how much a skill's damage/duration etc goes up per attribute point spent on it, correct? --Crusty 11:10, 18 Aug 2005 (EST)
 * Relative increase, straight from the horse's mouth. The talk page for it is also interesting.  --Fyren 11:30, 18 Aug 2005 (EST)


 * The fact that we are having this heated debate of the meaning and value of those tables means that it is highly subjective information. This does not make it useless information, but I think it needs to be sorted out and presented in a more objective and explanatory manner.
 * For example, I look at relative increase the opposite way you do. For example, I have an Elementalist char who is a secondary Mesmer. My favorite pet secondary skill is Backfire, especially if I anticipate facing a monk boss. Why? Because I cannot really invest much in a secondary attribute (most of my att pts are in Air and Energy Storage). So, with just 4or 5 pts in Domination magic, I am able to do 60 dmg with Backfire. Granted, if I have domination up to 12, I could kill the enemy spell-caster just by looking at him, but for my situation, skills that have a large "relative increase" are my friend in my secondary profession. Can you fault me for that? I hope not.
 * The point is that it is SUBJECTIVE. So, please stop trying to convince us it is global facts. --Karlos 13:16, 18 Aug 2005 (EST)
 * Sadly, that's not what relative increase describes. Check the talk page.  What you probably want is the simple rate of change (as in the slope of the line plotting attribute value versus skill value).  --Fyren 13:29, 18 Aug 2005 (EST)
 * Oh, I understood that, he's trying to measure the slope of the linear function compared to it's constant bias. Or as he says, the m compared to the b. My point is that I don't care about m's and b's, I care about which skill will give me the most for what I have to spend on it. I think the BEST reasoning for why I don't like this whole thing is provided, once again, by the horse: Relative_Increase
 * He is basically ignoring all of reality for the sake of mathematical purity. When I am making a build or distributing my attirbute points or choosing my skills, I am thinking about all those things he decided to ignore. Hence, the irreconcilable difference. :) --Karlos 14:37, 18 Aug 2005 (EST)
 * It ignores so much, just because you cant put that in simple formulars, and it still works if you just keep the unmatematical stuff in mind while building, like normal. A build that cares for relative increase of skills is ~15% more effective (more damage, more healing ...) in its skills overall than a build that doesnt! looking at relative increase makes the difference between a newbie build and a build that knows all the skills. Power leak and/or mind wrack are low-domination substitutes for Backfire (wich is medium domination, so its not all bad do use it woth low domination), try them in your build and tell me if it improves or not. Anyways backfire at 5 aint bad at all and of course it depends on actual situations. Try to use more than 20 differens skills overall, if you have them. Enough skill arguing --Ollj 16:49, 18 Aug 2005 (EST)

This vote is about the use of templates and the use of range variable articles. This argument has veered so off-course as to become irrelevant. I don't give a damn about reletive increase. Nevertheless, there are people who do, so it's worth keeping. Its current form is, frankly, horrible, and it isn't understandable by the average person&mdash;not because we don't understand the math, Ollj, but because we don't understand your "English." You clearly don't speak it as a first language. That's okay; we'll fix it up, eventually, when an editor who cares comes by it. However, right now, none of the other editors, as far as I can tell, care much about it, so it's doomed to languish. You need to find somebody with a better grasp of English than you to help you with this, translate the information properly, and write some cohesive articles about it. There is no problem with including mathematical/powergamer data on every skill page. Most readers may find it useless, but to be fair, most readers find the "flavor text" useless too. We should keep all valid data, regardless of how useless many, including myself, may find it. Work on making it readable, and ask others here for help, and we'll eventually have some extremely useful skill pages. &mdash;Tanaric 18:15, 18 Aug 2005 (EST)

I just found the holy grail of the green numbers. Soon all the range pages and its templates will be gone for something more usefull andd simpler that relies on the same data. And this page gets a rework and a simpler version (as introduction) of itself. --Ollj 08:37, 20 Aug 2005 (EST)

Targets, AoEs, and Methods
This was originally brought up at Talk:Skill Template Guide. The gist of it is I think it might be worthwhile to add three fields to the skill template: target, AoE, and method (of activation/execution). Here's the summary:

Target
What the skill can be used on. This is what the skill is "aimed" at. Choices are self, ally, other ally, pet, undead ally, enemy, and any. I think this covers everything, but I haven't scrutinized every skill (the actual list may even turn out to be smaller, I need to do more testing). "Undead ally" is the game's term for allied undead minions. Putrid explosion lets you target a friend or foe; it's the only skill I know of that can target "any."


 * self, ally, other ally, pet, undead ally, undead, foes undead, foe(s), creatures, corpse, all pets, dead ally pets --Ollj 20:44, 23 Aug 2005 (EST)


 * "Foe" is enemy. I have no idea what you mean by "creatures."  (If you mean Otyugh's, I suspect that targets yourself.)  No corpse spell actually targets a corpse (if you use zealot's fire and cast, say, well of blood, it damages around you, not the corpse).  I suspect all the non-attack pet skills target yourself, if the attacks target the pet, pet will be one choice.  The minion spells all target yourself, except Verata's gaze, so you're right that there needs to be enemy undead.  Thinking about it more, dead party member needs to be one, too.  --Fyren 21:17, 23 Aug 2005 (EST)

AoE
What "area" the skill affects once it is activated. Choices are target, adjacent, nearby, area/location (the game's keywords for it), party, corpse, spirit. Again, I haven't scrutinized all the skills yet, but I think this covers them all. If the AoE is actually an area (as opposed to target, party, or corpse), it's centered on the skill's target.


 * +targets adjanced, +own adjanced, +2 more adjanced, +4 more adjanced, +2 nearby


 * I have no idea what this means. --Fyren 21:18, 23 Aug 2005 (EST)

Method
How the skill does its thing. Choices are touch, attack, magic projectile, and automatic. Scrutinized, everything, yadda yadda. Touch are the spells that require you to touch your target (be in melee range). Attacks are skills that, well, are attacks (they can be blocked, evaded, etc. as if they were a normal attack). Magic projectiles are spells that travel and then strike, so have a chance of being dodged as if they were arrows, but can't be blocked, evaded, etc. Automatic are everything else. Things that just happen. Automatic is probably by far the largest.

Comments? --Fyren 18:46, 23 Aug 2005 (EST)

+targets adjanced, +own adjanced, +2 more adjanced, +4 more adjanced, +2 nearby actally touch is just the skills range, there still is barely any research on skills ranges. --Ollj 20:50, 23 Aug 2005 (EST)


 * Agreed. Someohow I feel we had this discussion before. :) I think "Method" should probably be called "Application." i.e. how the skill is applied. And "Automatic" should be called something like instantanuous or something. --Karlos 20:52, 23 Aug 2005 (EST)


 * All spell ranges are the same, except the one ice spell that notes otherwise. You could call touch just melee range, but there still needs to be a distinction, because "automatic" and "magic projectile" are 'normal' range.  We might as well go with the in game term and its semantics.  All attack skills seem to be melee range.  --Fyren 21:22, 23 Aug 2005 (EST)


 * Can you dodge/block touch spells like Shock? Also, I never saw the term "automatic damage" in the game. Where is that? For example, Chain Lightning is "automatic" but it doesn't say it's automatic. --Karlos 21:28, 23 Aug 2005 (EST)


 * No, you can't dodge or block touch spells (I tried (but apparently failed) to make that clear by contrast with attacks in the first place). And I meant go with the in game term "touch," not automatic.  (Though "magic projectile" is a game term, too.)  --Fyren 21:34, 23 Aug 2005 (EST)

Elite Skills
I think that Elite Skills should be marked as such MUCH more prominent than they currently are. Somewhere, so time ago, I read that somebody is working on the skill template. I would suggest to add something like the following to all elite skills:

Preferably this should be part of the skill template, but I gotta learn how to format those first. :) --Tetris L 21:16, 5 Sep 2005 (EST)

Acquisition
I am very unhappy with how the "Acquisition" section currently looks: Your opinion? --Tetris L 21:16, 5 Sep 2005 (EST)
 * 1) Do we have any fixed order to list the means of acquisition? By alphabet? By priority? By the order that you meet them in the game?
 * 2) I'm not quite happy with the order "Method: NPC/Boss, Location". Personally I think it should be: "Method: NPC/Boss (Location)". In any case the method should be first. This helps to create a tree structure if there is more than 1 NPC/Boss for the same method.
 * 3) As already discussed at length in Talk:Meteor_Shower we need to establish a standard about whether at all or how to list bosses that you encounter after the skill trainer or quest. I think it would be most confusing for users to list them in a mix with the ones that you meet before the skill trainer or quest. If we list them, then we should clearly separate them from the rest.


 * We HAD decided on the order quest, capture, trainer because of "cost." It's also not supposed to be "How: What, Where" but " Where: How, What " with the 'how' being either capture, quest, or trainer (unlinked) and 'what' being the boss name, quest name, or trainer name.  I don't really like the list/tree thing for capture, but I don't think there's much of an argument for or against it that's not just aesthetics.  As pointed out in that talk page, for capturing "before" might not be "before" but "somewhere I don't want to go on my second+ character since I don't have to."  Even so, listing all the Old Ascalon boss skills would be too much, but it's hard to draw a line.  --Fyren 04:15, 6 Sep 2005 (EST)


 * Can you capture from Old Ascalon bosses? If not then this wouldn't be a problem, we need only list those bosses from which it can be captured. 03:21, 6 Sep 2005 (EST)


 * Yup. You just need a signet first.  --Fyren 04:15, 6 Sep 2005 (EST)

I started checking through the skill trainer list and found lots of errors in the acquisition section of many skills (Dakk aside). This information needs to be updated urgently! I am willing to go through each and every skill and update the acquisition section. Considering that we have roughly 470 skills, this will be enough work for a WEEK. I could use some help!

I agree quest>capture>trainer is the correct order, because of "cost". I still think How>What>Where makes a lot more sense than Where>How>What, but that's a matter of taste.

As for bosses: I hope we're not going to list each and every boss in the game to capture skills like Orison of Healing. We'll end up with foot-long lists that nobody really needs.

Anyway ... before I go to work I wanted to ask: Would anybody mind if I use a table format for this. The code is rather simple, so Wiki newbs shouldn't have problems updating it. This is what I'd suggest:

I like this a lot better than the old list layout, but that - again - is a matter of taste. Your thoughts? --Tetris L 00:39, 23 Sep 2005 (EST)


 * I agree the acquisition sections may be out of date, a lot of details have changed and some remain missing. If you are willing to go through every skill and update them all then that would be a tremendous help!!
 * Personally, I would mind if you used a table, because I don't like it. The information does not need to be tabularized, it's fine as a list format. There are only 3 pieces of information, and there will generally only be 3-5 ways of acquiring each skill. When you compare the inellegance of both the wiki-code and the resultant displayed output of using a table with the simplicity of using a list, well, I think the comparison speaks for itself. I don't think I could be persuade that templates would make the job any easier either. I really think lists are the best and easiest option :) 02:39, 23 Sep 2005 (EST)