Guild Wars Wiki talk:Formatting/Skills/Archive6

Related Skills Revisited

Since no real decision was made, and since it is still causing problems, I would like to revisit the ideas for Related Skills. The "See Also" section is going to be more trouble than it is worth, trying to decide which mechanics make skills similar enough to list, etc. Instead of a separate section for skills which are potentially mechanically similar enough to be used in the same way by some players for some builds, just include those skills with the related skills.

Using Magehunter Strike as an example, both Protector's Strike and Magehunter's Smash are listed as related. Prot Strike is used as a quick hit of damage after Deep Wound, or after a spike for the last bit of damage, and MH Smash can't be blocked by enchanted targets. This is the perfect example of a skill that lists related skills based on both function (unblockable against enchantments) and usage (quick activating attack).

Now, I understand that not all skills will be this precise when it comes down to it. But we can leave the condensing of skills up to general consensus and common sense.

Hopefully we will be able to get an actual vote, or decision, rather than a few different proposals and a couple Yays and Nays here and there. FleshAndFaith 01:30, 20 September 2010 (UTC)

You have to look at what skills are used for:

• Magehunter's Smash is used to (A) knock stuff down. The skill is good at this because (1) enchanted (protted) foes can't block it.
• Magehunter Strike is used to (A) do big, fast, frequent damage. The skill is good at this because (1) it has a fast activation, (2) it's got respectable damage, and (3) it's unblockable against enchanted (protted) foes.
• Protector's Strike is used to (A) do big, fast, frequent damage. The skill is good at this because (1) it has a fast activation, and (2) it's got respectable damage.

"Hitting through prot" isn't something that attack skills are designed to do; attack skills are designed to do something and "hitting through prot" assists the skill in serving its primary function. Because of this, Magehunter's Smash and Magehunter Strike aren't really related in usage because they're not used for the same thing, at all; they're not related any more than Power Leak and Ether Feast (oh joy they both cause energy loss!).

Now, skills that are used for the same should be in one section (doesn't matter which, tbh) listed on the page; the other skills that "do" the same thing should be linked on List of skills by related subject or Skill quick reference.

Savvy? — Raine Valen 2:05, 20 Sep 2010 (UTC)

Not savvy, my impaired friend. The exact uses for an skill can be highly subjective as in the Life Sheath case. Some may use it to prot against a spike whereas others see it as an efficient spammable condition removal.--The Emmisary 02:16, 20 September 2010 (UTC)

Life sheath is both a soft spike prot (like RoF) and a spammable condition removal (like RC). It varies from Mark of Protection because Mark of Protection is neither of those things. It is not a spike prot at all because it has a 2-second activation time, nor is it a spammable condition removal because it is neither spammable nor a condition removal.

LS and MoP don't share a common application; they share a common mechanic. Mechanical similarities should be noted at one of the two skill lists (which really should be merged, but that is another topic). — Raine Valen 2:34, 20 Sep 2010 (UTC)

Very well then. I will remove MoP from the list. To be honest, I prefer mechanic over use but this is a wiki so I guess use wins. On a side note, all I know about the Life Sheath war was that it was over related skills. I tried to read the discussion but fell asleep 2 sentences in.--The Emmisary 02:43, 20 September 2010 (UTC)

(Reset indent) Heck, if we're trying to differentiate Relation by Application or Relation by Mechanics:

Related Skills

Common use	Mechanical ffect	Both
Weapon of Remedy	Mark of Protection	Reversal of Fortune
Xinrae's Weapon	--	--
Restore Condition	--	--

Not that ^that^ is a good compromise, but what about the general idea? --Riddle 02:55, 20 September 2010 (UTC)

Slight revision to your table if you don't mind | 72 | 03:04, 20 September 2010 (UTC)

Even then, you've got to draw the line someplace. For example, take Shielding Hands and Life Sheath: they're both soft spike prots, but, outside of that, they've got totally different characteristics.

I propose the following:

• Two list pages:
  • One details mechanical relationships;
  • The other details functional relationships.
• Each skill page lists the following in two separate sections:
  • Mechanical categories that the skill falls into (e.g. on "Mind Blast" page: skills that deal fire damage, skills that depend on target's energy, skills that depend on caster's energy, etc.)
  • Funtional categories that the skill falls into (e.g. on "Rust" page: elementalist spike-damage skills, elementalist cover hexes, res-control skills, etc.)
• This way, people can search for exactly what relationship they want.

The issues with are that:

• It would take extensive amounts of work.
• It would generate huge skill listing pages (unless they were separate subpages from the outset?).
• Categorizing skills by functionality is still subjective.

Long story short, it'd be a pain in the ass. I'd be willing to help, of course, but it's still a lot of work. — Raine Valen 3:12, 20 Sep 2010 (UTC)

The only thing that bothers me is that as far as I can see, Related Skills on most pages are already hugely biased toward mechanical. I noticed these 4 uses of Related Skills when looking at randoms:

• Mechanical, as in Phoenix, Castigation Signet (in function, CS gets you energy. Almost all its Relateds do huge damage, their main connection being "if target is attacking"), Mind Freeze, Rodgort's Invocation (the first two are related mechanically, but if you look at their energy costs, might be hard to use in the same function), Shadow Form (based entirely on "not targeted by spells"), and Divine Intervention < > Judge's Intervention
• On the other hand, Angorodon's Gaze is an example of the preference for function
• Some where it's related by whether you should use both at the same time, like the third one on Rodgort's Invocation
• Some outright strange things, like the sections of Disrupting or Distracting Blow, Chop, Stab, Strike -- which don't all agree (esp. Stab), and none of which mention Shot, either

It's quite a mess in places, though mechanical is the connection I find most often... | 72 | 12:55, 20 September 2010 (UTC)

Yes, that is because it was done poorly in the past with BOTH kinds of skills being put in the list, so clarification was sought, the policy changed, but the pages never updated. I've already said my piece about which information is more useful and I oppose it being removed, especially in favour of the information I consider less useful, but I have no objection to everything being retained in a reasonable manner. In fact, that was what the whole see also section proposal was about. A compromise so that no information was removed, without reducing the value of the information by mixing it all up together. Raine's proposal is ideal if someone can come up with a viable way of putting all that information there. Then of course, someone actually has to do it. The original problems arose because of the ambiguity of the policy, "related" doesn't actually mean much of anything and it was interpreted in at least two different ways. The see also section as it currently exists (on the few pages it does) is actually much more informative and understandable than anything that has ever been in the related skills section (which could really use a rename), so I don't see how anyone who wants information on mechanically related skills to be available could ever complain. An incredibly powerful method has been proposed and put into policy, just no one has apparently ever cared enough to use it, just enough to start drama. Misery 14:03, 20 September 2010 (UTC)

The other issue is that the wording is still quite confusing. It mentions functionality a lot but depending on the person "functionally similar" may mean "mechanically similar" while others may assume similar in usage. Granted, function and similarity in usage is more closely related in terms of definition, but obviously some people don't go for the obvious similarity. Maybe some kind of wording change can be done to make "usage" a clear priority in terms of listing in the related skills section instead of "mechanics". --Lania 18:29, 20 September 2010 (UTC)

(Yeah. I think "Common usage" is probably the least ambiguous way to describe it.)

The one I'm mostly in favour of is letting Related Skills have a wider usage, one that includes both sides' preferences.

But since agreement on that seems unlikely I would also be in favour of officially letting See also handle one of them, and I don't much care if it's the mechanical or common-usage type that stays or moves. If mechanical stays, maybe Related should become Similar; if common-usage stays, maybe Related should become Alternative or Substitute?

(However, if we do that, I also think that See also should be able to note specific skills, and not only lists of skills. It would be a huge and probably disappointingly unuseful task to find every list that every skill could fit into; so, while some, like "causes knockdown", "returns energy", or "slows enemies" would be useful, "decreases its own recharge" or "causes foe to damage self" would be better represented by the closest examples to the skill in question.) | 72 | 19:28, 20 September 2010 (UTC)

The problem with having every skill that have similar mechanisms is that it can make the page very cluttered, and isn't very useful gameplay wise because the usage is so different. While the wiki is built to document the game, I think it should also consider how the skills are used and we should just simply ignore mechanistic similarities skills that have no common gameplay application. To document mechanistic similarity while ignoring actual usage is just documenting the game for documentation-sake, which isn't as useful imo. --Lania 21:18, 20 September 2010 (UTC)

(This part of the discussion has been done to death). Personally, I don't much care what the standard usage of skills is, but I can see that it would be useful.

We aren't PvXwiki, and don't often document popular play e.g. we list ecto as 100; under Notes it mentions how it's viewed in the game today.

The connection based what happens when you activate it (unfortunately named "mechanics") interests me much more. I enjoy learning about skills that do the same thing.

However, unlike some people on both sides of the spectrum, I don't see why we only have to have one. As for clutter, I think that having 2 separate sections or some other visual marker (like a small table or a show/hide thing) would help.

Note that we don't have to be "liberal" as to what's related, any more than we would have to if we did only mechanical or only common-usage! We're not discussing "by how far of a stretch" the skills are connected, but are deciding by what standard(s) we judge connectedness. | 72 | 23:11, 20 September 2010 (UTC)

I think that's where things go wrong... popular play is not the same as "functional usage" or how the skill is used in-game. Just because a skill isn't popular doesn't mean that we shouldn't document similar "functional usage" of a skill. I think skills that are similar by "functional usage" is more interesting, and more useful for more people that read the wiki and want to make their own builds. Grouping skills just because it has similar wording but completely different use, is neither helpful or interesting for most people. --Lania 23:36, 20 September 2010 (UTC)

Your opinion doesn't speak for everyone else.Some people prefer to see mechanical similarities. --The Emmisary 23:42, 20 September 2010 (UTC)

Yeah, as the previous discussions on this subject have shown, there are plenty of people that feel both ways (some rather strongly).

(And yes, popular play is the same as how the skill is used in-game -- unless you mean there's a more objective way it's used than the way most people actually do -- which would be "mechanical"... :P) | 72 | 00:06, 21 September 2010 (UTC)

The problem then arises, The Emmisary, where you have people with no idea what they're talking about trying to pretend that skills like Mark of Prot are anti-spike skills, and are placing them on real anti-spike skill pages and claiming they do the same thing. That doesn't cut it on a wiki. The original point of the section was to suggest viable alternatives for skills (or, barring that, skills that are so closely related that they should be mentioned, even if they aren't necessarily viable). I still support that take on the related skills section - there are more than a thousand skills in Guild Wars, and most of them are trash by ANet's own design. Trying to make related skills sections huge and bloated with lists of skills that are related only in theorycraft-land is not an improvement over the current system, it's actually quite a step backward.

I wouldn't mind a separate section for "useless skills that do the same thing," as long as it doesn't interfere with the "these skills do the same thing and do them well enough to be a replacement for the original skill" section. If someone can come up with a way to display both without making the page look bad, feel free. That table Raine threw together could be a decent start, but it needs a lot of work. -Auron 00:31, 21 September 2010 (UTC)

Very true Auron, but aren't wikis supposed to dumb down the game so morons understand it?--The Emmisary 00:40, 21 September 2010 (UTC)

If you're of that opinion, I think that you'd agree that it's better to spoonfeed morons only the very best information: if you were a moron, would you rather wade through a bunch of skills to decipher viability, or would you prefer to have a section that simply says "this skills works; you can use it for this"? — Raine Valen 0:43, 21 Sep 2010 (UTC)

Not exactly, morons don't know whats good for them or care. Therefore just give them all the information they desire and they can sort out the specifics themselves. ( I trust if you are reading this you are not a moron and will not take it out of context).--The Emmisary 01:07, 21 September 2010 (UTC)

^^^ Come on, let's not escalate this into a pointless fight... no reason to assume that most people are morons (or even less intelligent than the editors)...

Auron: I don't think that problem is going to arise (or was even suggested by Emmisary's one line?), since that's what this discussion is addressing: that the rather confused Related Skills standards currently in place, which led to the kind of violent suddenly-on-the-job disagreement like with LS, should be regulated. Into only common-usage or only mechanical or both.

(To be clear it's not "useless skills that do the same thing", but "skills that do the same thing [but which, in common builds, have a different role]".)

I'm glad you agree that you wouldn't mind a separate section, and yes, I think not interfering is something everyone wants. | 72 | 01:14, 21 September 2010 (UTC)

(Reset indent) Good grief, did anyone read what Misery said? It actually made sense. So, addressing Raine's proposal, I think that such categorization of mechanical effect (and potentially related skills, if I read that correctly) could be done without necessarily listing every relationship but rather just those worth noting (Also, I don't know exactly what is already covered by categories/existing lists). I would hope that what to include or not would be fairly obvious and limited to more specific effects rather that "deals fire damage" or similar. This would require a minimum of discretion on a per skill basis but hopefully people would be able to handle that. --129.161.205.103 01:24, 21 September 2010 (UTC)

It turned off track about 3 posts down from Misery's (read the 2 after for more thoughts in line with Misery's).

And -- yes, absolutely; as I replied to Lania (quite similarly to what you said) there's no reason why mechanical relations have to be more liberal than any other kind of relation. Probably, discretion about whether skills are related would be aided by, say, requiring that the descriptions contain the same verbatim phrase, or something. | 72 | 02:12, 21 September 2010 (UTC)

I will reiterate my point and see if I can't try to clarify many things I ranted on about:

Mechanical relationships (or, how the skill works, rather than for what purpose the skill is used) are sometimes necessary when listing related skills. Now, the problem I see with two different lists for related skills is that it can create a mess, and it can be confusing (assuming the argument above, that the average wiki reader is a moron, is true).

If we amalgamated the lists into one we could make everyone happy. Obviously we would have to restrain some skills, make sure that Orison of Healing isn't linked to every single skill that causes healing, and other such silly things. And as Auron said (somewhere between the backhanded insults and nonsensical banter), we don't have to list EVERY single damn skill that is even remotely similar, just enough to give people an idea of potential alternatives.

Also, I should clarify: I said list just because that is what we currently have. I am all for a chart, or some kind of something with more clarity than a list, but I don't think we should completely dismiss a list just yet. I think Raine's given us a very good foundation, and all we need to do is figure out where to draw the line.

A few final thoughts: Auron, we don't have to cater to people who want to be spoonfed and won't think for themselves. They can mosey on down to PvX Wiki and have someone tell them exactly what skills to run, what armor to bring, and where to go, if the information here isn't instructional enough. And finally: The reason we have related skills based on player usage in the first place is because people saw functional similarities and decided to replace their bars with something that worked better or a bit differently. I don't believe we should discourage people from continuing to explore the little nuances of this game just because a majority of people have found a few builds that they like and don't want to branch out a little in terms of skill selection. FleshAndFaith 20:54, 23 September 2010 (UTC)

If you amalgamate all the lists into one I am not happy. I don't think everyone will be happy at all. If you put all the lists in one there is no explanation of why the skills are in the list. You could end up with Restore Condition and Reversal of Fortune being related to Life Sheath, one because it is used for condition control and one because it is used to catch spikes, but neither related to each other. Mark of Protection thrown in because it has similar mechanics, no relationship to Restore Condition. Why are they related? Well I explained reasons in that sentence, but an amalgamated list provides no explantion or reasoning and just becomes a giant bundle of skills. Can you explain to me why you think more information which is more clearly set out is bad? A list of skills with a named relationship seems much more moron safe than a mixed list. Welcome back by the way. Misery 21:28, 23 September 2010 (UTC)

I really like Raine's idea since it's not an amalgamated list, and it provides the explanation of relationships that Misery is talking about. I don't think the actual goal should be to make it "moron-safe" though... I'd like to say to reduce frustration, confusion, and annoyance while weeding through the useless related skills list. A new "intelligent" player will quickly find fault with an amalgamated list and quit using it as a reference point, and the wiki will lose some credibility because of that. If an intelligent player wants to explore skills, they'll just read the skill descriptions and figure it out on their own without the "help" of a confused related skills section. If someone can diagram graphically how major skills are related by use, that would be pretty neat. --Lania 21:41, 23 September 2010 (UTC)

In agreement with above posts, though favour non-mixed list

By the by, is it possible to do multiple columns of regular text without the whole messy/graphic-y look of a table? (I would find 2 adjacent lists most visually appealling/accessible.) | 72 | 22:06, 23 September 2010 (UTC)

Thanks, I'm happy to be back. Also, I didn't say we should just combine the two lists and be happy about it. I was in agreement that a list may not be the best way to go about presenting the information, but that we should not completely dismiss the idea without some consideration from everyone. Charts can get messy, and lists can be misleading, but both are viable options if we can figure out the most informative and least confusing manner to present the relevant information. Like I said, Raine has given us a good starting point, and it would be foolish not to run with the ideas.

Also, I didn't say we should list every possible relation, only those which make sense. For example, earlier I spoke of "Enchantments that heal when they end". We have to take into consideration many factors, such as: Can you target an ally with the enchantment? What does the enchantment do for you before it ends? Etc.

In this case, we could say that Shielding Hands isn't related to Blood Renewal, but BR and Vital Boon are related. Why? Because SH can be placed on an ally, it offers damage reduction, and the heal is, arguably, not the reason it is used. Conversely, BR and VB are both self targeting, both affect your Health before they end, and both heal a significant amount when they do end, whereas the heal from SH is considered a sweet little after-thought. See there, I have added a mechanical relationship which also includes some player usage, and doesn't ramble on with every single "Heal on End" enchantment in the game.

Like I said, this is something that won't be identical page to page. Some skills are similar in both function and usage, and so those skills will already be related. If you think about it though, it is the same way with Related Skills now: Not every possible use is going to be listed for each skill, only the most common ones as determined by the majority. So the majority will just have to determine what the most common uses are, and the most logical mechanical similarities to other skills.

Final thought for this post: I am concerned that you (Misery) are worried that a skill like Life Sheath will have, let's say, Mark of Protection and Weapon of Remedy as related skills (based on function and usage, respectively), and in turn, someone will make Mark of Protection and Weapon of Remedy related to each other on their individual pages. Or, perhaps someone will see that they are both related to LS, and assume they are related to each other as well. We can't really be held responsible for people's assumptions and for general human error. What else can that person do but click the links and either say, "Hmm, MoP turns damage directly into healing, like RoF and LS, but I think I want to use some life stealing instead, so I will go back and check out Xinrae's Weapon or Weapon of Remedy." Like I said, we shouldn't be held responsible for people's assumptions. FleshAndFaith 22:37, 23 September 2010 (UTC)

I've said like six times I don't mind the information being there if it can be put in a good, understandable way. The current list system was my attempt to put the information there. It's not perfect because I don't really care about mechanical relationships, so I am not going to put effort in to find the perfect way to ensure they are still there. As for the Shielding Hands example, that is actually a very good example. The whole reason this came up in the first place was because someone insisted it was related to Vital Boon. They used it on their healing dervish as fuel for Signet of Pious Light. If you go for mechanical similarities you cannot exclude anything without dictating how information about mechanical similarity can be used. What you are suggesting is far more restrictive than what was implemented. Lastly, that is not my concern at all. My concern is that the reasons why skills are related will become unclear. Misery 06:35, 24 September 2010 (UTC)

(Sure you can dictate it: look for likeness in the descriptions; verbatim preferred) | 72 | 13:48, 24 September 2010 (UTC)

Except that doesn't rule out what he is wanting to rule out. Vital Boon, Shielding Hands and Blood Renewal all say "gains health on end", just one can target all allies, the other two only yourself. Misery 14:54, 24 September 2010 (UTC)

Correct. I was against opening the flood gates and letting every skill with 1 thing, even if it was a small 1 thing, be put on a list. And again, the mechanical relations will be decided by general consensus (just as the most common use for usage based relationships is done now). The only concern I have at this point is how to present the information. Again, I think a chart is the way to go. However, I don't believe we would need a "Both" column. A skill that is both related by usage and mechanics should already be listed in the Related Skills section. It is fine if that skill is listed with the Related by Use skills, to sort of give that section some priority for new wiki readers. This way Auron's sheep friends can have their easy to understand information, new readers have a guideline laid out nicely, and slightly more ballsy users can see mechanical relationships and decide if that warrants trying out a new build to see if it is better or worse. FleshAndFaith 15:33, 24 September 2010 (UTC)

Well (as I said briefly on the LS talk page) you just have to focus on main/unique function instead of side functions. Easy, intuitive rule: the more common any function is, the less likely it is to be the main function of the skill (e.g. heal on end and health gain on end are both quite common). So, I think it would be pretty natural to say that Vital Boon increases your max HP and Shielding Hands reduces damage received; and though I can't decide because I don't know it very well whether Blood Renewal is mainly HP regen or large end heal, either way it doesn't really match up with VB or SH mechanically.\

(Similarly, this is why Life Sheath is functionally but not mechanically related to Dismiss Condition: condition removal is extremely common. And it's mechanically but not functionally related to Mark of Protection; turning damage into heal is relatively rare. And it's not related by either way to Smite Condition.) | 72 | 22:14, 24 September 2010 (UTC)

Now that we have established that a "One size fits all band-aid" fix for every skill won't work, let's move on to how to present the information. I'm still in favor of a chart. I was thinking we should keep the related skills header, for quick reference (this should go without saying, but I'm gonna say it anyways), then a 2 column chart with skills related by use on the left, and mechanics on the right. Now, I'm not entirely sure the right words to describe the columns. I was thinking "By Usage" for the left, and "By Mechanic" for the right. But will those be clear enough for the average reader? FleshAndFaith 18:52, 26 September 2010 (UTC)

Can I recommend making an example? Misery 18:54, 26 September 2010 (UTC)

(Edit conflict) No, we haven't established that, at all.

In detailing mechanical relationships, every mechanical relationship needs to be documented. This isn't a band-aid; it's surgery: it's as in-depth as one can possibly get on the subject. This is necessary because for both theorycrafting and general interest (the only two reasons given for detailing mechanical relationships), no relationship is decidedly more important than any other.

However, therein lies a huge issue: detailing every mechanical relationship is painstaking. For starters, the information has to be presented in a usable way, and that can be difficult when there's a billion different relationships. To this end, I proposed subheadings that filter from general to specific. Please note that, by nature, almost every skill would have to be listed under multiple headings. For example:

• Heavy Blow would be listed under:
  • Skills -> Attack Skills -> Warrior Attack Skills -> Hammer Mastery Attack Skills -> (further subcategories) wherein it would be mechanically related to every other hammer mastery attack skill, and, therefore, every warrior attack skill, and, therefore, every attack skill, and so forth.
  • Skills -> Skills with Conditional Benefits -> Attack Skills with Conditional Benefits -> Attack Skills that benefit from Weakness -> Warrior Attack Skills that Benefit from Weakness -> Hammer Mastery Attack Skills that Benefit from Weakness.
  • A million other possible permutations of things that describe the skill mechanically.

As you can see from here, this would be a massive issue because of the number of permutations of categories that every skill will fall into. Note that the number of combinations of categories that describe each skill is exactly one, but the number of permutations is ridiculously high.

So I'm going to suggest something else. The current skill infobox holds tons of information on skills. It lists almost every variable that skills are known to have. If we had some way to search for skills based on combinations of their attributes (e.g. input "weakness trigger + attack skill", return "fierce blow, heavy blow, overbearing smash, etc."), it would completely and perfectly document every possible mechanical relationship between skills, given the fact that the skill infoboxes are perfectly descriptive.

Any other solution, I think, would be either (1) incomplete documentation or (2) more of a logistical nightmare.

As far as practical relationships go, there's more subjectivity, so there's no real clean-cut way to deal with that. — Raine Valen 19:19, 26 Sep 2010 (UTC)

I'm confused. All of the information you used as an example is already available. A user would simply have to search for a particular category in a particular style in order to see "Every hammer attack skill, every attack skill, every skill, etc". I'm not sure you understood my proposal.

I suggested we list skills which function similarly, not every skill that fits into a category. For example, Heavy Blow is currently related to Hammer Bash (KD at the cost of adrenaline), Stoning (KD vs. Weakened foes), and Yeti Smash (requires a condition for KD). The information for categories is already present on the skill page. You'll notice under the skill icon, there are some fields, including Profession, Attribute, and Type. There you can find more skills for Warrior, Hammer Mastery, and Hammer Attack Skills.

But, I am not talking about skill categories, I am talking about their mechanics and functions. How they work, not what they are. FleshAndFaith 20:12, 26 September 2010 (UTC)

Not every mechanic is categorized (in Heavy Blow's case, there's no "skills with a Weakness trigger" category) and it's impossible to cross-reference categories using any function of the wiki (even if there were a "skills with a weakness trigger" category, there's no search function that narrows it down to "hammer attacks with a weakness trigger", or some such).

There is no difference between what a skill is, mechanically, and how that skill works. There is in practice, though, and that is why we've agreed to have the two separated (unless I'm mistaken about that consensus). — Raine Valen 20:33, 26 Sep 2010 (UTC)

Mechanical relation =/= categorical relation -- that's why we have categories for the latter. (All Warrior Attack Skills are NOT mechanically related; Mantra of Recovery and Serpent's Quickness are.) And neither =/= common usage relation. (Which reminds me, the question isn't between having 1 or 2 ways of relating but 2 or 3.) | 72 | 01:45, 27 September 2010 (UTC)

"Mechanical relation [does not equal] categorical relation [...]; Mantra of Recovery and Serpent's Quickness are [mechanically related]."

We could categorize them both as "stances that reduce skill recharge time". Similar could be said of all skills linked by mechanical relationships. Therefore, all mechanical relationships are, in fact, categorical relationships. This is why Backsword's original suggestion was to create categories for them; it would be fitting. The only reason that that solution is sub-ideal is that there would be so many categories on several skills that it would border meaninglessness.

On another note, whether being a warrior skill is a mechanic or not is largely a semantics argument. I am inclined to skills that belong to a certain profession mechanically related because there are skills that, for example, only interact with certain professions' skill sets (e.g. Deadly Paradox), but, again, it is largely semantics. — Raine Valen 1:53, 27 Sep 2010 (UTC)

I severely disagree (and I wish I hadn't chosen 2 stances). It is not a semantics argument. Classification is not a mechanical relationship, at least not (as far as I understand) the way anyone would naturally use it, or as far as would be useful to the sort of people (represented in this discussion) who use mechanical relationship to find "what skills do the same effect". Again, there are Categories for the other sort of thing. Mechanical relationships are almost useless if grouped along with categorical relationships. | 72 | 02:34, 27 September 2010 (UTC)

All squares are rectangles, but not all rectangles are squares. All mechanics are categories, but not all categories are mechanics. Therefore, we could say that "Stances that reduce skill recharge times of skills" is a category for a mechanic, but "Stances" is not a category for a mechanic. It is a category for a type of skill, not the mechanic. FleshAndFaith 02:57, 27 September 2010 (UTC)

Again, every mechanically related skill is categorically related. Pious Assault and Crushing Blow both fit into "attack skills that inflict deep wound and deal unconditional bonus damage" mechanical category; QZ and Mantra of Recall both fit into "skills that reduce skill recharge time" mechanical category. Every mechanical similarity between skills can be categorized. Further, functional relationships can also be categorized

Conversely, Glyph of Essence and Mantra of Concentration do not go into the same mechanical category because, though they both prevent interrupts, they go about it in an entirely different way (that is to say that they use a different mechanic).

As for what I was saying about skills of a profession being mechanically related based on the function of skills like Deadly Paradox, that is a semantics argument. There's a non-arbitrary similar parameter among every assassin skill, and this is a mechanical relationship. However, this is not important because that parameter is already documented, so this change would not affect it much outside of restating it. Does that make sense? — Raine Valen 4:18, 27 Sep 2010 (UTC)

No. No one wants to see every single mechanically related skill get listed in the Related Skills section, so we will have to judge which mechanic is the primary mechanic, and determine which secondary mechanic (if any) is most prevalent when organizing and listing skills. Not to sound crass, but who cares about all those categories? This argument is for the Related Skills section of the skill page, which I am arguing should (where applicable) include the most prevalent mechanic shared by similar skills, which can also include shared purpose or usage. This categories talk sounds like it should be in another section altogether. FleshAndFaith 05:28, 27 September 2010 (UTC)

In case you missed it earlier:

"In detailing mechanical relationships, every mechanical relationship needs to be documented. This isn't a band-aid; it's surgery: it's as in-depth as one can possibly get on the subject. This is necessary because for both theorycrafting and general interest (the only two reasons given for detailing mechanical relationships), no relationship is decidedly more important than any other." — Raine

The mechanical category "enchantment spells that heal on end" should include Blood Renewal, Patient Spirit, Shielding Hands, and Vital Boon because they all exhibit that mechanic. Oh, some of them don't target other people? Well, that's a simple fix, too: subdivide the mechanical category further: "ally-targeting enchantment spells that heal on end". It is clear cut and dry; I don't see why we're trying our hardest to make it complicated by arbitrarily assigning "pirmary" and "secondary" priorities to mechanics, because that largely defeats the purpose of documenting mechanical similarities at all.

On a different subject, because the word "category" seems to be a source of contention, allow me to clarify. I'm not talking about categories, I'm talking about categories. To this end, I suggested a categorical list similar to the ones already in place; however, I do not like that solution because each skill would appear N! times, where N is the number of categories in the combination of categories that fits a given skill. To put it plainly, that would be a fucking. Enormous. List.

However, given that we did, indeed, decide to go with a such a list, the "mechanically related skills" section would be a simple (and perfectly objective) matter of listing the categories in which a skill appears (at least, those that have other skills in them). For example, Hammer Bash would say something along the lines of List of skills by mechanic#Hammer attack skills that cause the user to lose all adrenaline (wherein it would be related to Heavy Blow) and List of skills by mechanic#Hammer attack skills that cause unconditional knockdown if they hit (wherein it would be related to every hammer elite KD).

It's complete, perfect, unbiased documentation. However, again, the issue is that e.g. List of skills by mechanic#Hammer attack skills that cause the user to lose all adrenaline would appear as a subheading of two different headings, which would each appear as a subheading of several headings, and so on and so forth because permutations are stupid.

Now, I'm open to another solution that isn't a logistical nightmare, so long as it also features complete, perfect, unbiased documentation of a skills mechanical similarities with other skills. — Raine Valen 14:00, 27 Sep 2010 (UTC)

My solution would be to simply ignore trying to document every single mechanic and just let general consensus decided what information is most important when documenting Related Skills. The system for skills related by use would work well enough for this. An example: Life Sheath has skills related that are used to catch spikes. However, a Mechanic of Life Sheath is also its condition removal. However, we don't have any listed (other than Weapon of Remedy, but that is because it is used to catch spikes). This is not because we have a lack of documentation, but rather because there would simply be too much information and none of it would truly fit (physically or conceptually). I'm also not talking about labeling "main/secondary mechanics". I am talking about people deciding (in the discussion page) what mechanics of the skill makes it related to others, based on more than one aspect (if need be). My example, of course, was the Enchantments that Heal on End. Instead of listing every skill that fits, then subdividing them (many of which would be listed in multiple categories from there) I simply said we should ask ourselves what makes Skill A so similar to Skill B, and factor in other aspects such as the ability to target other, the effect of the enchantment before it ends, etc. This way we don't have to tediously document every single function and can have a helpfully concise list of 1-5 mechanically related skills.

To be honest, the categories/sub-categories/permutations project sounds more like a personal project. I don't see the need for compiling lists of skill functions like "hammer attacks which cause KD if your target is weakened and removes all adrenaline" which only really has 2 (if you consider Yeti Smash) skills.

Also, I just had a thought. Maybe instead of those long, complex headers, you could broaden the scope. Instead of "Spells that are Maintained Enchantments that can target other allies that cause healing when they end that give the target health regen while maintained" for Watchful Spirit... Maybe just a simple list: Enchantments that Heal on End, Attack Skills that cause Knockdown, Skills that grant health regen, etc. Some skills will be repeated, some will have a list all to themselves, but all the mechanics are there, without needing to describe each skill in their list perfectly. This way, the categories will be documented, and the related skills can still be more in depth based on how many different lists a certain skill is on, and what skills it shares those categories with. FleshAndFaith 16:37, 27 September 2010 (UTC)

Considering how angry you got with me and other people when we suggested Mark of Protection was not as related to Life Sheath as you think it is, can't you see why that is a bad idea? You are applying a band-aid that satisfies your specific complaint with no foresight for problems that could occur in the future. Misery 17:30, 27 September 2010 (UTC)

I cannot possibly agree to combining categorical relationships (SKILL TYPES AND HIERARCHIES) with mechanical relationships (EFFECTS OF SKILL).

They are useful for very different reasons, and I thought (and intended) the latter was being discussed, since we already have the former in effect.

The latter is the only one that has interest for people who like to browse through skills and see what other skills are like it; if they are combined, it will be diluted beyond usefulness.

That's all I have to say on the matter, so until consensus is reached as to how we'll be treating them as different ways of relating skills, I think I'll be silent since I could only contribute to the project in good faith depending on the outcome. | 72 | 22:56, 27 September 2010 (UTC)

Bold text doesn't indicate anger, CAPS LOCK DOES. Also, I'm not saying we should ignore these arbitrary categories, I'm saying we shouldn't try to fit a skill perfectly into only one category. As I said, we should not have a "Spells that are Maintained Enchantments that can target other allies that cause healing when they end that give the target health regen while maintained" category for Watching Spirit. However, we have several other categories like "Maintained Enchantments", "Skills that grant Health Regen", "Enchantments that Heal on End", etc.

My other point was this: We don't need to come up with a cut and dry system for every skill page to follow. We don't need a checklist for every skill to follow. We don't need to say, "Ok, this skill fits with 3 of the same categories, so it can be related to this skill. But this skill only fits 1, so don't list it." It all depends on the category, on the skill, etc. I think trying to come up with a single system would be a colossal failure.

Consider how related skills are chosen now (as I understand it): General consensus determines the main use(s) of a skill. General Consensus determines what skills have largely the same use(s). Those skills are then listed together. Why does it have to be different for the main mechanic(s)? FleshAndFaith 01:41, 28 September 2010 (UTC)

caps4clarity | 72 | 02:15, 28 September 2010 (UTC)

I would argue that personal attacks would suggest anger, unless you were deliberately attempting to provoke an emotional response, also known as trolling, which is frowned upon here. Only Raine has suggested anything approaching the specificity you alluded to. Just pick a random skill from the skill quick reference and see how already it is mechanically related to an absurd number of skills. That list isn't even approaching complete and contains no overly specific lists(in my opinion). That is why I want to see an example of what you want, because at the moment what you are saying makes no sense to me. Misery 07:51, 28 September 2010 (UTC)

I would argue that nothing is a personal attack unless one misconstrues it as such. It's not like I said, "Misery, you are a bad person and I think your taste in clothing is reminiscent of the 1980's, and not in a good way."

Anyways, here was my argument, with an example:

Numerous skills have more than one usage. However, general consensus determines the most common. In the case of Life Sheath, general consensus has determined that Catching Spikes is the main use. However, people do use it for alleviating pressure from damage and for condition removal. Now, instead of listing every skill that is used to alleviate damage and remove conditions (in this case, any skill which can remove 1 or any skill which can remove 2), they have decided that the main use is catching spikes, so they list other similar spike catching skills. I know in PvP, a great many people that use Infuse Health to "catch" spikes. Perhaps my definitions are mixed up, but completely healing an ally in the middle of a spike (effectively requiring a follow-up or second volley of the same skill) is a good way to catch and reduce the potential for a kill from a spike (or spike follow-up).

My proposal for mechanical relationships is largely the same. Instead of listing every single mechanical relationship, find out which ones are the most important (based on that lovely general consensus) and list them. To go back to the "Enchantments that Heal upon ending" argument, we would not just go listing every skill that fits that description, but get more in-depth by looking at other features. My examples included listing Illusion of Weakness with Faithful Intervention (they both can only be self-targeted, do nothing while active, require a "current health" condition to be met for removal, and last indefinitely until that time). Another example would be Vital Boon and Blood Renewal. They both are self-targeting, both affect your health while active, both last a set amount of time, and both heal you when they end. This approach would make these 4 skills unrelated to something like Patient Spirit or Shielding Hands (which can target any ally, do not affect health while active, end after a set amount of time, and are not removed by a damage or current health trigger.

See, I don't think we need a category for "Enchantments that don't affect health while active." That is a great number of spells which fit that description, and it is not important by itself. But when used to compare enchantments that have an effect when they end (in this case healing) it becomes relatively important. FleshAndFaith 19:47, 28 September 2010 (UTC)

"Numerous skills have more than one usage. However, general consensus determines the most common." — FleshAndFaith

Some skills are decidedly better than other skills from a usage standpoint. Consensus doesn't determine this; applied math and game theory determines this. If 99% of the players in Guild Wars think that Life Sheath is better than Guardian for alleviating attack pressure, 99% of the players in Guild Wars would be wrong. Their "consensus" does. Not. Matter.

Consensus is equally as unimportant from a mechanical statement. No skill is decidedly better at a mechanic than any other skill. That doesn't even make sense. Heavy Blow and Stoning are perfectly, completely, equally dependent on weakness for knockdown. Patient Spirit, Faithful Intervention, Shielding Hands, Vital Boon, Watchful Spirit, Blood Renewal, and Watchful Intervention all heal on end. It's a boolean variable: they do or they do not. If there is a "List of skills that heal on end", they all need to be included or the list is incomplete documentation, period.

Now, if you're suggesting a list of "Common skills that heal on end", then I'd like to ask you: in what situations would that ever be better than a complete list? For the third time, the only arguments presented for a mechanical list at all are "it could be useful for theorycrafting" and "it would be cool for general interest". In both of those cases, a complete list is strictly superior to a "Common" list.

I really don't see how this can be any clearer. — Raine Valen 23:51, 28 Sep 2010 (UTC)

(Well, not in the case of over 50%, since the game theory you say the math acting on, has for its variables nothing but common usage; if over 50% of the players used x instead of y, it would necessarily be because the things they were using x to counter were the ones that are weaker against x than y... :P) | 72 | 00:05, 29 September 2010 (UTC)

And that is why that list is subjective and dynamic. At any given point, though, one set of outcomes is correct and, ideally, that is the set of outcomes that should be documented. The meta doesn't change very often and, when it does, it should be documented. PvX does a good job of this with builds, so I don't see why we can't do the same with skills.

Also, some skills are strictly dominated by other skills, so they would never appear ever.

Aside from this, was there anything else that you disagree with? — Raine Valen 0:15, 29 Sep 2010 (UTC)

Nope, not really :). (I'm only truly interested in the mechanical relationship, so most of what's being said, although I'm reading it, is out of what I feel comfortable discussing.. hence when I do, the small text to represent that what I'm saying isn't really significant) | 72 | 01:05, 29 September 2010 (UTC)

I'm going to have to point out that you didn't really say anything new or contrary with your "applied math and game theory" statement. I said that general consensus determines which function of a skill is considered the "main function". Yes, Math tells us that Healer's Boon is better than Unyielding Aura at rank 10 Divine Favor because of the duration vs. recharge, increase to healing percentage, decrease to casting times, and energy management. But many healing monks still use Unyielding Aura. Why? Because it has utility, it has 2 very strong mechanics which sometimes outweigh the benefits of HB.

Yes, a complete list of enchantments that Heal Upon Ending must have all skills that inherently heal when they end. (This reminds me of a little anecdote about a silly friend with a smart ass comment about Mysticism. Let's ignore this for now). However, in the related skills section of a skill page, we would not list all skills that inherently heal when they end. We would have to look at more than one such category, and other variables. Yes, a properly documented category of enchantments would include ALL of them. No, an informative subsection of a subsection of a skill page would not have to include all skills from every category fitting a single skill.

Raine, I notice while looking at [[categories]] that each of those skills are not related to each other on the skill pages. Just using the first skill, Agonizing Chop, as my example we can see that it is only related to Critical Chop and Disrupting Chop, neither of which are listed as Spike Follow-Up skills on that list. I don't quite understand the point of showing me this page... As an example of how you want to document skill mechanics? Sure, we can get a team of people to work on it and put every skill in every category it could feasibly fit in. But how will that affect the Related Skills section? I'll give you a clue: It won't. FleshAndFaith 05:02, 29 September 2010 (UTC)

"My solution would be to simply ignore trying to document every single mechanic and just let general consensus decided what information is most important when documenting Related Skills. The system for skills related by use would work well enough for this." — FleshAndFaith

"Numerous skills have more than one usage. However, general consensus determines the most common." — FleshAndFaith

You said that skills' functional usage is " based on consensus". You used this as a premise for proposing that skills' mechanical relations also be based on consensus. However, I said that your premise is wrong because skills' functional usage is not based on consensus. Your conclusion (that consensus can determine the strength of a mechanical relation) is incorrect because it's based on an incorrect premise.

"Yes, Math tells us that Healer's Boon is better than Unyielding Aura at rank 10 Divine Favor because of the duration vs. recharge, increase to healing percentage, decrease to casting times, and energy management. But many healing monks still use Unyielding Aura. Why? Because it has utility, it has 2 very strong mechanics which sometimes outweigh the benefits of HB." — FleshAndFaith

Guess what? Healer's Boon and Unyielding Aura are both mechanically related and functionally related! They have a common mechanic: they increase healing by a percentage. Does one do it better than the other? Yes. Does that matter for a boolean list? No. They have a common application: monks use them to increase healing by a percentage. Is one used more frequently than the other? Yes. Does that matter for a boolean list? No. The difference between the two would be that UA would also be in a "resurrection skills" subcategory and HB would also be in a "skills that increase casting speed" subcategory. That is all. Everything else you've said in that paragraph is totally irrelevant, unless you're proposing a far more detailed system.

"Yes, a complete list of enchantments that Heal Upon Ending must have all skills that inherently heal when they end." — FleshAndFaith

Yes, it would. I asked you earlier what purpose an incomplete list would serve, and you're yet to name one.

"However, in the related skills section of a skill page, we would not list all skills that inherently heal when they end." — FleshAndFaith

No, we wouldn't: we would link to the "list of skills that heal on end". Once. That would be all of the required documentation. And it would be complete and unbiased.

"We would have to look at more than one such category, and other variables." — FleshAnd Faith

Yes, we would. We'd have to look at every other such category that a skill belongs to, and link those on the page, as well. It is very simple.

"Yes, a properly documented category of enchantments would include ALL of them. No, an informative subsection of a subsection of a skill page would not have to include all skills from every category fitting a single skill."

You're right, a list of dozens of skills on a related skill page would be silly. Instead, we place a few links on the skill page that point the reader to exactly what relation they are looking for. I said this a long time ago.

"Raine, I notice while looking at categories that each of those skills are not related to each other on the skill pages." — FleshAndFaith

The skills aren't related to each other on the skill pages because the skill pages are done poorly. That is why we are having this entire discussion.

"I don't quite understand the point of showing me this page... As an example of how you want to document skill mechanics?" — FleshAndFaith

Yes. The section I worked on is proper documentation of skills from a practical standpoint. It's not as specific as it could be, but that can be fixed subsequently.

"Sure, we can get a team of people to work on it and put every skill in every category it could feasibly fit in. But how will that affect the Related Skills section? I'll give you a clue: It won't." — FleshAndFaith

If you'd shown me the courtesy of reading what I wrote, you'd see that creating said lists is pretty vital to linking them in the related skills sections. I've said everything in this post in prior posts. I would appreciate if you read what I've already said so that I don't have to reiterate myself several more times. — Raine Valen 14:03, 29 Sep 2010 (UTC)

I never said that general consensus determines the strength of a mechanical relationship, I said that general consensus can determine which combination(s) of mechanical functions is most useful for listing skills based on mechanical functions. Also, I feel you are greatly misunderstanding me, because I never said that I wanted to list categories of related skills, but rather that I wanted to list skills. Linking people to the Skill Quick Reference page is all good and well, but my point was to list the skills themselves on the skill page itself, like related skills already are. I'm not sure when exactly the argument was changed from listing skills to creating complete lists of every possible skill use and every possible skill function. Honestly, the latter of that is the only one possible, since listing every use of every skill would rely too heavily on conjecture and would be considered incomplete documentation.

To clarify (since I am always misunderstood):

• I am for the idea of detailing a complete and informative list of skills based on their mechanics (such as the Skill Quick Reference page) and linking them (the categories) to the bottom of a skill page, where relevant.
• I am against the idea of attempting to list every possible skill use for every skill. I believe such a list would inherently be incomplete, peppered with conjecture, and misleading to new players/readers.
• I am for the idea of listing mechanically similar skills in the same fashion as related skills are currently listed.

I hope this helps you unmuddle my ideas. FleshAndFaith 23:55, 29 September 2010 (UTC)

I agree with Faith. (However, I'm not sure how 1 and 3 are compatible. If by 3 you mean that the most important mechanical relations will be listed like they are now instead of only as categories the bottom of the page, but that less important ones will be down there as categories, I agree with that.)

I also add:

• I am for the idea of combining Faith's 3rd point with another one, where the word "mechanically" is replaced with "common usage"

I hope this helps you unmuddle my ideas as well. | 72 | 02:58, 30 September 2010 (UTC)

Yeah, that's is pretty much what I mean. There's not a great way of saying it without reverting to the same examples, but I try. The only thing is, I wouldn't use the word "important" I would say, "relevant" instead. What is relevant is up to general consensus, but it is largely wardened by common sense and logic. Obviously we aren't going to list every skill in the "Skills that Affect an Area" Category together, simply because they are not all used the same way for the same ends. What we can do, instead, is look beyond the face of the list and see why they are different. Some are movement snares, some cause knockdown, some have an ending effect, etc. We would have to pick, as the majority, which skills are mechanically related enough to warrant being placed in the same list.

And, of course, under the list of skills, we have the links to the categories the skill belongs to. A wiki reader can be given popular and helpful examples of skills which can be used to the same effect and skills which share a rare mechanic (or several of the same more than rare mechanics), and then immediate below that, they can find a link to a section of the Quick Skill Reference which is relevant to the skill they are looking at. They can be spoon fed by examples, then they can do more research into it, if they so choose. FleshAndFaith 03:25, 30 September 2010 (UTC)

This shit is pretty whack. Whatever you guys do, remember not to touch the "viable related skills section." List all the bad skills in the bad related skills header (or in the bad related skills chart, however you end up doing it). -Auron 06:53, 30 September 2010 (UTC)

Mechanically Related Skills: Draft 0:

Two part proposal:

1. List of Skills by Mechanical Relation:
   • Subdivided several times until the point that a category could no longer be divided and continue to contain multiple skills.
     • For example, Targeted AoE Hex Snares is a subset of Targeted AoE Snares.
       • Because of this, the categories are smaller and more precise.
       • This way, the categories linked on the skill pages themselves include only the skills that are most related to the skill in question.
   • Categories do not overlap ever.
     • For example, if there is an "enchantments" subcategory of spells, there will not be an "enchantments" subcategory of any other category.
       • This limits the list size significantly.
       • However, this also requires significant cross-referencing on the user's part to yield the greatest amount of information.
2. Related Skills: (On skill pages.)
   • Includes subheadings that are links to the most specific categories that the skill is in that includes other skills.
     • For example, Life Sheath's page would have a link to List of Skills by Mechanical Relation#Skills that remove multiple conditions as a heading, under which other skills that remove multiple conditions would be included. It would also include a link to List of Skills by Mechanical Relation#Skills that convert damage to healing, where other skills that do that would be included.
       • This makes skills very easy to reference at a glance.
       • Because the headings are links, this also makes it very easy to seek more information. For example, clicking the link to List of Skills by Mechanical Relation#Skills that remove multiple conditions on Life Sheath's page would show that it was a subset of "skills that remove conditions", so users could pick other condition removals if "multiple-condition removals" is too specific.

How does that look? — Raine Valen 3:47, 30 Sep 2010 (UTC)

Anything is better than the current format (is there one?), however: in your life sheath example, would Dismiss Condition (single condition removal) be related to Reversal of Fortune (reversal of damage)? I think I'm missing something, but it'd be interesting to find out. 71.191.39.32 04:16, 30 September 2010 (UTC)

Seriously... sandbox your proposals or no one will undersatnd what they actually end up like in practice. This isn't only directed at you Raine. Misery 06:35, 30 September 2010 (UTC)

Mechanically Related Skills: FaithAndFlesh's Drafts (1,2,3):

Draft 1

The chart is difficult to manage and maintain (it was for me, I've never done one before). But its the idea I was trying to portray, with the added contributions for skill categories. FleshAndFaith 18:48, 30 September 2010 (UTC)

Oops, forgot some comments. In the case of that particular skill, all the mechanically related skills from the category linked at the bottom fit in the chart on the page itself. It is a rather rare mechanic, which is why this is the case. FleshAndFaith 18:50, 30 September 2010 (UTC)

Looks pretty swell (though 2 minor wording changes: "Player use" = "use of players" or "use by players"? ;) and for See also, is Categories appropriate or should each skill use that section title, which seems to me reserved for, like, "more information on the subject of this article"?) | 72 | 19:38, 30 September 2010 (UTC)

Word choice is not my forte. I need a word that says, "Players also use these skills for the same purpose(s)" but I'm linguistically beaten at the moment. How would one describe skill relations based on player usage in a small phrase? FleshAndFaith 19:58, 30 September 2010 (UTC)

Here is Draft 2, which has more than one category which links to the skill reference page. As you can see, RoF is listed as related by use. Technically, it is related to both, but I think giving priority to the "Player Use" column will be more helpful to new players. I'm still deciding if adding it to both columns would be helpful, or just redundant. Obviously, if a player is looking for a replacement skill, or related skill to accent their skill bar, they wouldn't have to look any further than skills related by use. As for the links at the bottom, I'm just calling it "See Also" because that's what it's called now. But you can see that the mechanics that fit in Life Sheath are just linked in that section without needing different headers. I'll make another for skills that have slightly more diverse categories. Oh, and I think for my drafts, since for now they are simply being used to show different examples of the same layout, we can just keep them in this header.FleshAndFaith 20:10, 30 September 2010 (UTC)

Draft 3 As you can see by this one, I have listed only some of the mechanically related skills from the list of enchantments with end effects. I listed these because these were ones which affected your health while active and heal upon ending, rather than doing damage or causing a condition. Then, just a few clicks below that, you see the skill category for enchantments with end effects, effectively giving you prime examples of related skills which you may consider, and complete documentation of all enchantments with an end effect. FleshAndFaith 20:29, 30 September 2010 (UTC)

Is your left column meant to show potential substitute skills? I see the advantage of listing a subset of these, but I don't understand the value of listing only some of the mechanically parallel skills. Why aren't the links at the bottom good enough?  — Tennessee Ernie Ford (TEF) 21:07, 30 September 2010 (UTC)

Yeah, aren't the lists supposed to replace the related-by-mechanics skills? --JonTheMon 21:48, 30 September 2010 (UTC)

That's not what F&F and I were thinking (if you look up to the clearly marked for and against above); we like the idea of being able to see what satisfies our interest, in the same way other people would like to see what satisfies their interest. But then, since most of the people who didn't even mind having both were more in favour of common usage, all but the important/relevant/closely connected (it's not easy to nail down) few would be relegated to the bottom.

I like draft 2 best so far (with the most relevant mechanical skill(s) still listed visibly, with a greater proportion at bottom). | 72 | 01:53, 1 October 2010 (UTC)

Yes, the left column shows potential substitute skills. And the links at the bottom of the page aren't good enough because they don't have a pretty little picture next to them which compels people to click on them. Furthermore, the Related-by-Mechanic skills go deeper than "What skills are also on one or more of the same lists". In the case of Blood Renewal, I linked the reader to a list of Enchantments that Have an End Effect. However, I have listed only a few, the reason being that those particular enchantments HEAL when they end. Now, since we have a list of Enchantments With an end Effect, I don't think we need a subcategory for enchantments that Heal upon ending. Otherwise we would keep subdividing them down until basically every category just describes one skill.

Basically, the chart says, "Here, we have taken the liberty of picking a few skills which we believe truly fit with the skill in question, both by what the skill does, and by how it does it, to save you the trouble of wading through a much larger list with every skill which shares one of the same mechanics. However, if you want to look into it more yourself, below is a link to the entire list of skills which shares this one mechanic."

This way we have a bit of relevant information for the spoon-fed, and every single bit of information for the more adventurous reader. FleshAndFaith 03:10, 1 October 2010 (UTC)

Maybe we could end our collective silences and discuss these drafts. Pick them apart and rebuild them please. I would also be interested in seeing Raine's proposals in a sandbox.... FleshAndFaith 18:47, 9 October 2010 (UTC)

Yeah I was kinda waiting to see what Raine proposed for changes, but she hasn't been on the last several days it seems? :-/ Personally I don't think we need anything with mechanics since it's already in the categories, but at the same time I don't mind it being there. Also I like draft #2 the most. --Lania 19:01, 09 October 2010 (UTC)

Still no response from Raine. Seems she has been on, just hasn't checked this section in a while. I'd like to move ahead, if we can, and pick apart my 3 drafts and see if we can't pick and choose the qualities we like and dislike about them. Hopefully we can start making progress again. FleshAndFaith 01:26, 17 October 2010 (UTC)

It has been 5 months with a consensus supported compromise on this project. I believe you have the right to move forward. Hopefully, Raine will return but the show must go on. I don't see a difference in the three drafts other than the number of category lists on the bottom. I will say that the table makes excellent use of the space provided without causing any clutter, it looks very clean. All three are exactly what we need to close this function/mechanic gap and sets a much needed resolution to this long time argument in motion. These are my additional suggestions:

1. I personally think that the "See Also" section should be below the "Related skills" section since they are related to each other, rather than separating them by the notes section, which can be quite lengthy on some pages, and makes the process more "convoluted".
2. "By Player Use" and "By Mechanics", I prefer the terms "Function" and "Mechanic" I find the term "Player Use" to lack definition, I am not interested in holding up the process over this one little issue, this disagreement should only be noted for consideration.TheRealGriz 10:01, 19 March 2011 (UTC)

Page needs to be changed

I was half tempted to just change this myself but due to the sensitivity of the subject I am asking for a consensus as to how this should be handled.

Under the "Related Skills" section a "catch22" has been created.

• Related skills may be included under following rules:<--missing the word "the"
  • Skills that are functionally similar, such as single target snares, AoE DoT spells, etc

Now, "Functionally" is an adjective that means "of or pertaining to a function" and "Function" means "the purpose for which something is designed or exists" (IE the result or final effect of the skill)

• Related skills may not be included under following rules:<--missing the word "the"
  • Skills with only common similarities (for example Signet of Judgment and Shield of Judgment offer knock down from the Smiting Prayers attribute line but have completely different mechanisms)

Mechanism means "the agency or means by which an effect is produced or a purpose is accomplished." (IE how the skill is implemented)

So the article is stating that a related skill should be included if it has the same final effect on the target, but should not be included if it has the same final effect on the target.

Continuing the problem it also states:

• • Skills with similar functionalities and one common similarity (like stance removal + being an attack: Wild Blow and Wild Strike are linked together but Mark of Insecurity is not).

This is redundant because it already states "Skills that are functionally similar" should be included, this just adds an additional requirement that is superseded by the previous statement that does not require this requirement, thereby making it not only redundant but also obsolete.

After reading through all the previous comments, as well as the formatting guidelines I can't determine what consensus has been reached, but it looks like the "Mechanism" (how it is applied) of the skill, and not the "Function" (the final effect) of the skill, is the preferred method to be used. Am I correct in this assessment and should it be corrected on that basis? TheRealGriz 20:57, 17 March 2011 (UTC)

There never really was a consensus reached. I pushed forward with my idea to the point of frustrating those who pushed another direction, leading to a decline in interest all around. I would like to revitalize the discussions, but several of the main parties have gone on to other things. FleshAndFaith 00:10, 19 March 2011 (UTC)

I read the wall-o'-text as saying that (most) people (posting) prefer to see a short, tidy list of skills that can be used as sensible substitutes. No one has any objection to links to longer lists (e.g. mechanically similar skill lists, such as skills that heal on ending). Notably Flesh & Faith has proposed an alternative, but I don't read that there was a lot of support for it (soz, F&F).

@Griz: your above analysis suggests you have an idea for how to rephrase the current formatting guidelines for skills. Could you put something together on a subpage or sandbox page so folks can take a look? I think everyone is burnt out on the theoretical discussion, but I, for one, would be interested in reading your proposal. Thanks.  — Tennessee Ernie Ford (TEF) 23:35, 20 March 2011 (UTC)

I do have an idea and I agree with you on the community burnout, if I were to have full control over it I would do this: Example If I were to just make a quick change to solve the problems I would focus on two issues.

The following line of text is a virtual loophole that almost any skill could fall into, it is both vague and has very little (if any) parameter and undermines BOTH of the subsections of "Related Skills". I would remove it completely. Just as I did in my example:

1. Skills that are functionally similar, such as single target snares, AoE DoT spells, etc.

The following line of text is completely arbitrary and thus problematic, I would remove it completely. The build maker should determine if a skill is useful or not, not the guidelines. Either it is related or it is not.

1. Skills making the current skill obsolete or less wanted (put them eventually in Notes section)

Because of these conflicts we have a wealth of "Related Skills" issues and little to none of it makes sense. As an example Backfire has Empathy and Pain Inverter listed as "related" they all are hex spells, they all have a duration, they all have when target foe does something it takes damage. Empathy has Pain Inverter listed as related but not Backfire and Pain Inverter has neither one listed. And if you look at all of those that are listed you will find a whole number of skills that don't connect to the next.

One more example but from the opposite view Signet of Clumsiness has Bane Signet and Clumsiness listed, Bane Signet is listed because they both cause knockdown if target is attacking and both are signets, they have 2 functional similarities plus one common (both signets) but completely different mechanisms, which is within the guidelines. Clumsiness is a hex spell with completely different mechanics as well, but they have only one functional similarity (they both cause interrupt resulting in damage). These skills should be related by a list of skills that cause interrupt, in the "See Also" section at the bottom. How can this be edited when someone can say but they have "Functional Similarities" because of a guidelines loophole. On top of all that Signet of Clumsiness is not on the Clumsiness list for related skills. It's a mess and the guidelines are most of the problem.

I think we need to focus more on what should NOT be in the list and less on what SHOULD be in the list, and use that foundation to clean up these pages by closing loopholes and arbitrary interpretation. I have no interest in discussing the theoretical burnout part of it, but rather to enable editors to use the guidelines to achieve the intended purpose, and rely on consensus of individual pages for other specifics. TheRealGriz 09:45, 21 March 2011 (UTC)

Well I would like to add my two cents into this argument. I have recently been seeing a lot of different skill that have been labeled as related but I could not see how. After taking a closer look I saw many of the examples that TheRealGriz used in his statement as being very true to what is. This is an extreme problem that people including myself see, as without PvX wiki anyone that is creating a build has to sort through the +/- 1300 skills too come up with a build that works for there needs. As for the Idea that TheRealGriz used in the sandbox I like it, as a matter of fact a lot. I would like to see this implemented. If we could come to a censensus then we will have a better platform for Guildwars2 with less complaining about what skill should go with what and why. Iron Fireforge 20:48, 22 March 2011 (UTC)

Current situation with related skills is far from perfect, this is often an area of the fruitless discussions, arbitrary additions/removings, reverts etc. Although current recommendations in guideline are not bad itself, they are often not taken into account. Some wiki editors even don't leave any summary about reason why they have changed the list in particular case. On other side, I don't think that idea with classification by mechanics like in the table proposed above is suitable for most of cases (unavoided empty cells in such table look not well at all), but no explanations at all is a bad thing too.

My suggestion is: any section with related skills should contain the explanation and/or comments. The similar features and replaceability can be explained either in a brief preface before the list of skills, or immediately after the particular skill, like it's already done in many lists. Some examples: Hex spell (not complete, but gives some info), Condition#List of conditions (rather well), Stance#Related skills (a good example). Such brief description or comment should help to understand the similarity and also explain a reason of including the skill in the list. I think that no special recommendations are needed for such comments, it's a matter of practice, which can be started right now. Though this cannot eradicate the arbitrary changes, the requirement to make comments should force authors to think more carefully and leave the reasonable explanations, which can be a matter for useful discussion in unobvious cases. --Slavic 21:02, 23 March 2011 (UTC)