Guild Wars Wiki talk:Formatting/Skills

From Guild Wars Wiki

Contents 1 Suggestion 2 Bad......Bad.....Update 2.1 Gray texts in concise descriptions 3 redundant doubled type mention 4 Skill sounds 5 ID 6 skill tables/lists and concise 7 Related skills 8 Skills with separate PvP versions 9 Suggested boss capture. 10 Forms and Disguises

[edit] Suggestion

I suggest to call everything not cast by monsters or players effects. Mainly I want this to separate their categories and infoboxes, because they are not related in any other way than that they are called "skills" in the game integration links. The skill infobox is already doing autotyping and autcategorization that doesn't fit these other skills. This could be reworked of course, but I'm afraid the box code would get so huge and complicated we would end up with something slower than actually keeping two boxes in mind. - anja 13:56, 16 December 2007 (UTC)

Fire Dart: it's in-game type is Skill, it has a recharge time, it appears in the damage monitor, but not in the effects monitor, it comes out from a trap but saying it is casted would be misleading, the trap is not a player and is not targetable like NPCs, and of course, it's not "learnable" and has no profession. This thing is a skill, our only problem is the skill infobox autocategorizing it as a Common skill and having, like usual, an ignorant user adding Special = Environment effect skill. Solve that.reanor 16:55, 16 December 2007 (UTC)

All of them are skills, and all skills have effects, some can be seen in the effects monitor, some in the damage monitor. But it's true that those called 'effects' can be never be in a skilbar, Environment Effects, Item Effects, etc...

So you suggest doing nothing, Ereanor? I don't get your point, actually :/
See poison for an example where things are really messing up. Poison has no attribute, of course, and is also categorized with all the player used skills. It's neither a core skill nor a common skill in the usual sense we refer to those categories. - anja 13:34, 6 January 2008 (UTC)

Well... poison is a condition, that means an effect triggered by other skill. Remember the lava pools? They can deal crippling and burning. MithranArkanere 19:56, 6 January 2008 (UTC)

Actually, we call Core any skill that is found in more than one campaign even if it's not a player skill. And what I'm suggesting is fixing that damn skill infobox.reanor 16:09, 6 January 2008 (UTC)

Ok, what about trying to incorporate everything into the skill infobox then. What would be needed to change? I'm thinking we could make a list so we can get this sorted. A few points:

• Autocategorizing (huge issue)
• Remove attribute from things unrelated to attributes
• Sort effetcs/conditions into subcategories of Core/common skills?

- anja 19:59, 6 January 2008 (UTC)

I would - as a player - never call those skills, I am unable to use, as core. When I sort the skills by campaign, the Core skills are those I can learn in any campaign. I would like to split those skills I am able to use and those I only can see. Nobody is interested in a list where monster skills and player skills are mixed. Or those where effects/conditions are listed along with a Resurrection Signet.. poke | talk 20:06, 6 January 2008 (UTC)

Here is my take on this issue for what it's worth. The only things that should be listed as Effects are Area Effects such as those found in DOA and Dasha Vestibule mission to name a couple specifics, I'm sure there are others. These are things that create continual effects on you unless certain conditions are met. They are not affected by aggro range, or other skills. I see Fire Dart as a monster skill, cast by an inanimate monster, the fire trap. This is not an effect, as it is affected by aggro range and can be blocked/negated with player skills. Things like poison, blind, cripple, etc.. things that also show up in the Effects monitor are actually conditions, or effects of a skill, where the skill is categorized, not the effect.-- Wynthyst 21:03, 6 January 2008 (UTC)

To make it easy: Three types of skills

• Player skills - All skills that can be used by a player
• Monster skills - All skills that cannot be used by a player but are used by monsters, npcs or unselectable objects
• Effect skills - Everything else, categorized in the categories which were documented in the Effect infobox description.

All skills do have a campaign, player skills do have an attribute. poke | talk 21:35, 6 January 2008 (UTC)

I would see Effect skills as being the area affects only. Effects triggered by skills should be a subset of either player skills or monster skills. Conditions are subsets of either skills or Area Effects. Consumable Effects are a category of their own, as are Item and bundle effects for all cases where the bundle is not created by a skill (ie ritualist's item skills). Trying to encompass all these as a separate category is doomed to fail imo.-- Wynthyst 21:46, 6 January 2008 (UTC)

i'm inclined to agree w/ anja. conditions getting listed as common skills needs to be changed as it's not a player or monster equipped skill. also, regarding fire dart, i don't agree w/ it being a monster skill simply b/c it's not a monster that casts it. it's a part of the environment as much as lava is unless u wanna start calling lava an inanimate monster. fire dart is only still a common skill b/c i overlooked it while changing skills like Ice Dart to environment effects. i had a discussion w/ poke and backsword regarding this. --VVong|BA 22:52, 6 January 2008 (UTC)

I just realised conditions isn't even handled as skills by the game; they have no game integration link. Thus, conditions should be on it's own (for those who prefer to label everything in game integration/skills as skills) or be under a more collective, not as official maybe, heading like effects. - anja 10:29, 7 January 2008 (UTC)

IIUC they are intetionally excluded to avoid them cluttering up the recently encountered list. Backsword 11:18, 10 January 2008 (UTC)

From where did you get that info? If we base what is skills on the game integration, we should follow it. Either we just include those as skills, or we make our own groups from scratch. - anja 11:22, 10 January 2008 (UTC)

Some developer comment sdomewhere. Don't have source handy, it's just what I remember. I don't really mind one way or the other what they're called in wiki functions, as long as no one is confused. They're the same type of technical entity tho'. Backsword 11:31, 10 January 2008 (UTC)

"unless u wanna start calling lava an inanimate monster" - Fire Dart is afaik - similar to the other Dart skills - a skill which is casted by those stone things. Not by lava.. poke | talk 17:14, 7 January 2008 (UTC)

Maybe we could ask ANet how those skills are handled in game as I still believe that they are enemies which simply are not selectable.. poke | talk 17:15, 7 January 2008 (UTC)

Yea, possible. Kinda like the buffaloes on Shing Jea. -- ab.er.rant 17:20, 7 January 2008 (UTC)

Environment effects are skills activated by triggers, with our without animation. For the lava, 'entering' is the trigger, like with water, teleporting devices, healing shrines or smashing weights. I think that the traps work the same way: "enter area". Just like flaming traps, a fire arrow trap will target anything inside its area, but the animation will have an start and ending point, and be avoidable, unlike other 'area' animations. You could say that it is like smashing weights and giant balls. They are areas that 'move'. For conditions, thay are not skills, they are 'side effects' caused by skills. Listing them as skills would be like listing damage and degeneration as skills, they are effects caused by skills, yes, but not skills. It's just that we are used to see the effects of the skills have the same name as the skill.MithranArkanere 20:01, 7 January 2008 (UTC)

Actuallt, there is a Lava entity, and a Lava skill. Same as for those turrents. I don't know if they're implemented as unselectable creatures, bundles, interactive objects or some fourth type of skill user, but in any case, what they do is sit and spam a PBAoE skill all the time (every 1 sec IIRC in this case). That would be the lava skill in this case. The reason why you never see the lava skill is because it neither cause damage directly, thus no damage monitor, nor does it cause a lasting effect on it own, thus no Effect monitor, instead it applies conditions, and that's what you see. You can test this yourself, by finding spots where you get hit by lava despite visually being just outside it, or reverse, not being hit with it despite being just slightly into it visually. Backsword 11:28, 10 January 2008 (UTC)

Yeah, but what I mean is that effects like conditions, hexes, enchantments, etc... that appears in the Effect monitor are not the skills themselves, but an effects triggered by the skills. Conditions are effects of a skill, but not a skill; an hex you have it's not the skil, but the effect of the skill (You cast hex spells, but you have hexes on you); the damage you take it's not the skill, but the effect of the skill. For that, conditions are 'effects', but not skills. MithranArkanere 14:03, 10 January 2008 (UTC)

I'm using Thread Resurrection! Seriously, we need to resolve this. Articles about other things than player skills and some monster skills are a complete mess, with pretty much 15 different formattings. :P I still stand by my suggestion to call things we cannot see being cast (or secondary effects like conditions) but which are seen in the effects monitor "effects", but it's alot more important to actually get some kind of agreement on this. I see two possibilities:

• Call everything skills and adapt the skill infobox to work with it all (easier to remember, but very complex infobox)
• Use skills and "arbitrary non-official other group" to ease formatting issues and infobox issues. Effects is a suggestion, if you can find a better name, go ahead :)

Another solution would of course be to use more than two subgroups, but I get the feeling that would be overly complicated. Hit me if I'm wrong :) - anja 11:29, 13 March 2008 (UTC)

As I already said on some pages, I prefer a sub-division of skills into Effects with the definition that all skills which may be displayed in the effects monitor actually are effects. I would like to divide then into the effects which are actually skills (casted by players, NPCs) and, the rest, effects which only are activated because of some other action. The latter would then be categorized into Category:Effects which is a subcategory of Category:Skills.

Skills like Fire Dart which are "casted" by non-targetable NPCs (which really exist as also proven by the Bulls on Shing Jea) , would then be categorized in Skills but not in Effects, as they are not visible in the effects monitor.

It would be fine to me, to categorize things like Hex spells and Enchantment spells into the effect category as well as they are also effects. And if we use the Skill infobox or two infoboxes is rather unimportant as long as we follow specific rules. poke | talk 13:36, 13 March 2008 (UTC)

Mostly agree with poke. Maybe use these rules:

1. It is a skill if it is activated by a character, an NPC, or has a point of origin.
2. It is a player skill if it can be equipped and used by characters.
3. It is a monster skill if it cannot be equipped and cannot be used by characters.
4. It is an effect if it shows up in the effects monitor.
5. It is an environment effect if it shows up the moment a character enters its range.

Skills and effects are not mutually exclusive. A skill is a skill, but some of them are also effects. Conditions are also effects. Fire Dart is simply a monster skill possessed by the untargetable fire traps. Environment effects and terrain effects are all effects, but not skills, since they do not have a single point of origin (covering an area instead) and are not similar to the AoE of spells because they don't use the standard ranges that apply to skills, thus they are not skills. We can also break environment effect into location effects and terrain effects as well.

In this manner, the skills infobox would need to be expanded to take effect categories into account. Either that or we can split away all the effect categories from the skill infobox and apply effect categories manually because I see Category:Skills as being on the same level as Category:Effects. i.e. an effect is not a skill, a skills is not an effect. A skill can (not must) have an effect. An effect need not have an associated skill. -- ab.er.rant 02:27, 14 March 2008 (UTC)

So you want to call everything not cast by monsters or players, effects? or did your sentence just abruptly end? — ク Eloc 貢 05:59, 14 March 2008 (UTC)

With the extensive use of the word effect in concise descriptions, I get the feeling it would be best if we stayed as far from the word "effect" as possible. Backsword 09:55, 26 March 2008 (UTC)

I think the easiest definition for skills, especially when looking at the technical background, is: Everything which is displayed with a 48x48 icon is a skill. So is every effect internally also a skill. poke | talk 06:52, 14 March 2008 (UTC)

Ok, with some of the new results of browsing through Guild Wars, there are a lot skills like BAMPH! or Titans get plus Health regen and set enemies on fire each time he is hit. categorized wrong. I think we should definitely try to resolve the whole thing about how we want to categorize that different kinds of skills so that we don't have skill lists with those - for players unavailable - skills. poke | talk 00:52, 22 March 2008 (UTC)

Like List of monster skills? Backsword 09:37, 26 March 2008 (UTC)

Aye, this is a mess. There's no standard use, includeing with the skill infobox. One has to make up values for the 'special parameter as one goes along. Then there is the fact we don't know exactly how some skills are used, so defining them has that additional problem. Backsword 09:37, 26 March 2008 (UTC)

Player usable	Skillbar	Learnable	Unlockable (PvP)
			PvE
		Temporary	NPC placed
			Replacement skillbar
	Other activation	Title
		Consumable
Nonplayer usable	Monster			note:not player usable, but used by at least one NPC
	Object	Selectable, visible object
		unelectable, visible object		note:may be none
		Selectable, invisible object		note:may be none
		Unselectable, invisible object		note:may be none
	Unknown	On entry in area		note:may be object
		On interaction with NPC		eg. many blessings
		Other		note:may be none

OK, this is an attempt at a hierachy, to consider when sorting skills. Backsword 09:53, 26 March 2008 (UTC)

[edit] Bad......Bad.....Update

→ moved from Template_talk:Skill infobox

Sigh. Thousands of editing. Concise skills ftl. How is this going to be implemented into the infobox? A Concise parameter? Calor 20:41, 13 March 2008 (UTC)

Galil's job methinks. -- Brains12 \ Talk 20:42, 13 March 2008 (UTC)

I wish a bot could have done this.. But at least I'll have something to keep me from studying this weekend :D - anja 21:11, 13 March 2008 (UTC)

Yes, this should be Galil's sysophood hazing. Calor 21:16, 13 March 2008 (UTC)

(edit conflict) Yeah.. Calor: concise description is the parameter called and it is already implemented, so add the descriptions already! poke | talk 21:18, 13 March 2008 (UTC)

Add a header over the "normal" description named Traditional description? -- Brains12 \ Talk 21:20, 13 March 2008 (UTC)

Are we going to start adding the alternate "consise" skill listing along with the normal? if we are, I'll try to help in this endeavor (provided others are faster then my dial up >.<) Wandering Traveler 21:21, 13 March 2008 (UTC)

Bad Anja, should be studying =P --Kakarot 21:23, 13 March 2008 (UTC)

First of all simply add the short description. As I wrote in the section above, we probably will make some big changes to the Skill infobox, so we can discuss about how it exactly should look like later. poke | talk 21:26, 13 March 2008 (UTC)

Come on, they are only 1319 player skills and some monster skills, XDD. It can be done over time. Look on the bright side: Now we can decide categories even easier, since same behaviors in skills are described exactly the same. MithTalk 21:31, 13 March 2008 (UTC)

It's like adding the alternate names for each skill if you have GW in Bork Bork Bork language. It's pointless. I see no real reason to include the concise one aside from just for the sake of having all the information. Besides, traditional description is FTW. They already highlight the important parts of what the skill does anyway. Eldin 21:32, 13 March 2008 (UTC)

Having the concise ones on wiki for things like quick reference lists would be great, since those already take up huge amounts of space. - anja 21:35, 13 March 2008 (UTC)

I'd have to agree with Eldin. I don't think you guys need to waste your time editing every skill page with what is essentially just an abbreviated description. Both lines of text will say the same thing, just that one will have a few and's and the's taken out. My guess is that it would just look messy with two separate but the same descriptions listed. Clobimon Craiggy 21:40, 13 March 2008 (UTC)

if the description change i don't care, if it does'nt like for Charm Animal i don't see the need to repeat.--lussh 22:04, 13 March 2008 (UTC)

Some are really very different. It's a part of the game now, so we need to record it somewhere. It just looks a bit ugly atm. :P --Aspectacle 22:08, 13 March 2008 (UTC)

Example: http://wiki.guildwars.com/wiki/Heal_Party It's 5 letters shorter. ? Clobimon Craiggy 22:15, 13 March 2008 (UTC)

No I mean like: Purge Conditions. Most of the concise descriptions I could take or leave, but this one is vastly different and much, much better. --Aspectacle 23:27, 13 March 2008 (UTC)

(Reset indent) I don't see the benefit of using Concise descriptions for "quick reference" because they are shorter and take up less space. It just seems like less info on wiki is not such a great idea. I would like to see the Concise description added to the skill page with an easily identifiable heading for reference only. Full traditional descriptions should remain the priority for any reference lists imo.Lady Chevon 22:21, 13 March 2008 (UTC)

so you keep the double information for charme animal ? that's just wonderfully stupid. lussh 22:22, 13 March 2008 (UTC)

Agree with you Lussh that it doesn't make much sense to list redundant information. A notation that the Concise skill description is the same perhaps? More reason to simply stick with the Traditional descriptions.

The purpose of the wiki is to document the game. Every aspect of it. Does it hurt the wiki to have both the concise and traditional description? No. We don't need this completed ASAP, and a few pages will look ugly for a few days until the proper way to include the concise description is decided upon. To Eldin, this is likely going to be a popularly used feature. I don't think a whole lot of people run Bork! Bork! Bork! as their game language. And this is the English wiki. Bork! Bork! Bork! isn't English. It's Bork! Bork! Bork! :p. Some people will ignore the concise definitions, some will devote a lot of time to adding them to the wiki. It's your choice. But don't totally reject the concise description, because it belongs on the wiki as much as every other article does. Calor 22:35, 13 March 2008 (UTC)

Using Concise description is good for quick reference, it's not like we're going to be cutting out the original text as there will be a link leading to the traditional description.--Underwood 22:47, 13 March 2008 (UTC)

No, not a link. Just the traditional description right there, and the concise one right below that. Maybe heading(s). It all needs to be worked out. Meh, I misread what Underwood was saying. I thought Underwood was referring to skill pages, not quick reference pages. I'd prefer the traditional description on the quick reference pages (as is), but I'm not entirely opposed to having the concise description there. Calor 22:53, 13 March 2008 (UTC)

Agree with CalorLady Chevon 22:54, 13 March 2008 (UTC)

Unless they fix their horrid excuse for concise descriptions, I won't push for it anymore. Take a look at Bull's Strike vs Water Trident though, now that's bad.--Underwood 23:35, 13 March 2008 (UTC)

(reset) I personally dont not see a need or reason for reformating all the text to this new system... as noted in GW's update... you have the option of keeping the old format. And with this being a website for those your are learning the game... I think the longer discriptions would be better for those looking for information. SabreWolf 23:43, 13 March 2008 (UTC)

(Edit conflict) I'd be in favor of not showing the concise description on skill pages and only show the traditional description, but in quick reference lists, I'd prefer having it the other way around. — Galil 23:44, 13 March 2008 (UTC)

The issue I see coming up with that is it being cut/pasted in other areas on Wiki and then what is Traditional is lost. My first preference would be to not list them at all, but if they must be listed, to list them on skill pages ONLY with a subheading and the language.Lady Chevon 00:17, 14 March 2008 (UTC)

It wouldn't be copy/pasted. It would still be added to the skill pages themselves and nowhere else. We use Dynamic Page List for getting the data from skill pages. The only thing we would have to do is change a couple of parameters in a few templates. :) — Galil 00:19, 14 March 2008 (UTC)

Why don't we just complain with Gaile and ask Anet to call this update off? You know? like just cancel the shit.reanor 02:09, 14 March 2008 (UTC)

please no...I just spent 2 1/2 hours adding on those extra concises....ow. ok, if we have to. Wandering Traveler 02:12, 14 March 2008 (UTC)

Alright, here's the good idea. Let's add them with a Show/Hide button.reanor 02:13, 14 March 2008 (UTC)

The community will add the concise descrips whether we want it or not. just scan recent changes...its happening.--Ryudo 02:14, 14 March 2008 (UTC)

I like the show/hide idea.--Underwood 02:15, 14 March 2008 (UTC)

I don't, since it would reset every time you left the page anyway. Clicking "hide" each and every time you visit the page would just end up being a pain. — Galil 02:18, 14 March 2008 (UTC)

It would be great if the wiki stored the option in its coockies to save the option to show or hide any or both. MithTalk 02:19, 14 March 2008 (UTC)

It could work, but the question is if it's worth implementing a specialized version of MediaWiki:CollapsibleTables.js, when we could just decide on keeping them shown or hidden. ;) I still suggest only showing the full description on skill pages and the concise description in quick references. — Galil 02:22, 14 March 2008 (UTC)

I mean setting Hide as default of course! Think about it, how many ppl will actually open that useless thing? 99% of GW players are veterans already, we don't care if it's not there, let the newbies do the hard work of clicking "Show".reanor 02:29, 14 March 2008 (UTC)

But why would the newbies want to see the concise skill description? The point I'm trying to make is: Experienced players don't care what description is there and the newbie players would probably want the full description. Why should we have the full description visible as default and require them to click a link to show something they can already read? — Galil 02:36, 14 March 2008 (UTC)

Because we are just adding them for "full documentation of the game" and not for its usefulness. As far as I know, this is the dumbest update since Factions.reanor 02:54, 14 March 2008 (UTC)

(Reset indent) The show/hide thingy is not (edit: missed this word) going to be useful. Pick either the longer description or the concise one, don't do both. It's not necessary. I'm in agreement with Galil. Use the longer description for skill pages - that's why they're called skill pages, to find out the most you can about a skill. Use the concise description on reference lists. That's why they're called "references", they make it quick for for you to reference things. Click on the link if you want to know more. A wordy reference list will be inferior to a concise reference list. Also, shorter descriptions will probably make the table look nicer on smaller resolutions. -- ab.er.rant 03:08, 14 March 2008 (UTC)

"The show/hide thingy is going to be useful. Pick either the longer description or the concise one, don't do both." Contradictory? Or did I simply misunderstand? :P — Galil 03:16, 14 March 2008 (UTC)

Aberrant tends to be consensual. I think he meant he likes both ideas.reanor 03:18, 14 March 2008 (UTC)

as long as a page don't have twice the description i agree with everything. lussh 03:31, 14 March 2008 (UTC)

They will still have to be included on the various pages though, so don't remove them. If we decide not to have the concise descriptions on the skill pages, we will change {{skill infobox}}, not the skill pages. — Galil 03:36, 14 March 2008 (UTC)

Clarification: If we decide to use the concise descriptions for the quick references, the descriptions will have to remain on the skill pages for DPL to be able to grab the descriptions. This is so we don't have to edit every description in several different places. That's why we should modify {{skill infobox}} if we do not want them on skill pages. — Galil 03:39, 14 March 2008 (UTC)

I would still prefer to list both types on skill pages. Remember: we are a wiki to document the game. If we leave out that (important) bit of information on skill pages, which are - as aber said - "to find out the most you can about a skill", then we have to list that information especially on skill pages. If we then use the concise or the traditional style on the Skill list pages is another thing. poke | talk 06:33, 14 March 2008 (UTC)

IMO it's redundant though, cause even though they are both from the game, they basically say the exact same thing, just in different ways. Nobody interested in what Healing Breeze does would go to its page and think "why the hell can't they show both the full description and the concise description?" — Galil 06:38, 14 March 2008 (UTC)

I also think both skill descriptions should be displayed on skill pages. Having a show/hide thing will just inconvenience people who prefer the description that is hidden. Tedium 07:49, 14 March 2008 (UTC)

Eeek... I meant "not going to be useful" *goes to edit my previous comment*. I'm with Galil here in that I think having both descriptions is redundant since the short one is already better explained by the long one, i.e. redundant. But I realise that redundancy usually isn't a very strong counterpoint so you won't find me strongly opposed about it either. If we're dead set of putting two descriptions per skill, let's use "Normal description" rather than "Traditional description" though. -- ab.er.rant 07:57, 14 March 2008 (UTC)

Would it be possible to toggle the traditional/concise description with a button using javascript or something? That way people can view the descriptions they prefer rather than we decide for them. Tedium 08:27, 14 March 2008 (UTC) nvm, would have to default to one description so still not convenient. Tedium 08:44, 14 March 2008 (UTC)

Charm Animal still look strange repeating the description, how are you going to decide what to do ? i have nothing against the concise description, as long as it is indeed concise... i feel stupid having to say that... lussh 08:40, 14 March 2008 (UTC)

My first thought was to give the concise description a smaller font and an indent. Firstly to separate it from the old description, secondly to make it draw less attention. It is abit redundant, but it is still important to document, and we can't decide what preference "most people" will have. Thus, both on skill pages, but not necessarily the same weight for both. - anja 09:12, 14 March 2008 (UTC)

That sounds good Anja - I can definitely visualise that. On a formatting theme...Are there any thoughts on wiki links in the concise description? On one hand I could see them useful in skill listings if that's the only description there - but on the other you're duplicating links on the actual skill page and folks who like the concise descriptions in their lists probably don't need so wouldn't click on the links anyways. *shrugs* --Aspectacle 09:33, 14 March 2008 (UTC)

agreed for smaller letters size if i understood correctly, then even if it mindlessly repeat, at least it will draw less attention as you said. but i don't know how to do that. lussh 09:34, 14 March 2008 (UTC)

What Anja said ;-) I feel that not adding the new descriptions is simply not an option for a wiki, so we should work on a way to add them in a good looking way. --Xeeron 12:08, 14 March 2008 (UTC)

(Reset indent) some of the new descriptions aren't shorter in length, but they do all seem to follow a more rigorous wording convention. in effect, that makes the new wording objectively better than the old wording as long as u understand the convention. i don't think we can afford to not include the new descriptions. as mentioned by someone else, it would be nice if we could set a cookie to record user preference on which description to show. as it is now, showing both descriptions is quite aesthetically unpleasant. --VVong|BA 13:53, 14 March 2008 (UTC)

I insist, show/hide is the way to go. Yes, we have to document everything, but we work for players and wiki users, not for the game itself. Believe it or not, users are intelligent beings too! And they don't give a sh*t about this redundant new feature, we might as well not include it, and I'm pretty sure nobody would miss them. Still, we are adding it, and we know that it looks terrible, so the solution it's adding them, but also hiding them. And that's it!reanor 14:03, 14 March 2008 (UTC)

The problem is, I do care about these new descriptions. I love them, I will use them and I do consider myself an intelligent being still. We could try to bring up votes on what side has most support and whine all day, or we could try to find a solution that works for us both. - anja 14:10, 14 March 2008 (UTC)

I agree with Anja, I find the new descriptions quite interesting and I want to be able to read both. It's better to get ideas on how we should present them instead of if we list them both as that is quite clear for a documentating wiki.. poke | talk 14:36, 14 March 2008 (UTC)

After reading through this, I too agree with Anja's comment above as well as her idea regarding smaller text/indentation for the concise description. Since we are documenting the game and not select pieces of it; the pieces that we think the majority of players use; both descriptions need to be included. However if both descriptions are the same; for example Charm Animal; maybe have a paremeter where if it's set to yes the descriptions are combined into one with a header as Normal/Concise description and if set to no it displays both in the format Anja mentioned. Not completely sure if that's possible though. --Kakarot 14:51, 14 March 2008 (UTC)

It can be done. Templates are all about conditins and copypaste. We just need to set that if concise description text is 'same' or any other keyword we decide, then replace it with the same text as the normal. Or just do not put it twice, but replace Normal description text with Normal and concise description and put the description only once. MithTalk 15:09, 14 March 2008 (UTC)

Yea it's definitely possible and shouldn't be that hard to code :) - anja 15:20, 14 March 2008 (UTC)

(Reset indent) Just brainstorming here, but we can put <div>-tags on both descriptions with a specific class name and make a small help page on how to modify ones Special:Monobook.css to either show both, show regular or show concise skill descriptions. Perhaps not the most brilliant idea, but it is a possibility. --  (CoRrRan / talk) 16:04, 14 March 2008 (UTC)

Not to shoot your idea down, it is nice for wiki editors, but 99.9% of our users with never, ever touch their monobook.css. 99% wont even possess a user account. --Xeeron 16:42, 14 March 2008 (UTC)

I think Cor meant that more for those users who are totally against listing the concise description.. And then it's really an option. poke | talk 16:57, 14 March 2008 (UTC)

Alright. Here's my proposal. We've never put "Description: Skill. blah blah" in skill pages, we just put "Skill. blah blah" because a player knows. So, we won't put "Concise description: Skill. blah" for the same reason, and because it's plain ugly. Instead of a smaller font, wich could make reading harder, I've chosen italic and added a line (----) to divide them. Everything's there, looks nice, hope you like it. BTW: I'd rather we put all concise descriptions, even if they have the same text.reanor 17:03, 14 March 2008 (UTC)

Hm.. No, I don't like that.. What about something like that bit in my sandbox? poke | talk 17:08, 14 March 2008 (UTC)

I have to agree with Ereanor, both in those reasons and in the design (but maybe a little less conspicuous divide line) -- Brains12 \ Talk 17:10, 14 March 2008 (UTC)

About poke's idea, I just don't think we should give these descriptions too much of a special treatment by showing them smaller or giving them a header. Technically, in-game, normal descriptions and concise descriptions are equals.reanor 17:13, 14 March 2008 (UTC)

The concise description is special enough to have an extra setting in the option panel.. And there is not a combo box where you can choose between traditional and concise but only one to enable concise descriptions. poke | talk 17:17, 14 March 2008 (UTC)

I like both of your suggestions, they both make it obvious they are different versions. And poke, I don't think the header "Concise description" is even needed, the small font separates it enough already. - anja 17:22, 14 March 2008 (UTC)

How about this for a divider? (Aiiane - talk - contribs) 17:36, 14 March 2008 (UTC)

That's great! just a bit less color and less caps.reanor 17:38, 14 March 2008 (UTC)

Yea, not WOW but I like the idea alot :) If you can make it as "non-obtrusive" as the grey thin line, it would be great I think. - anja 17:40, 14 March 2008 (UTC)

Ereanor, the caps are mainly because as font gets smaller, lowercase becomes much harder to read than upper case. So the question is, which would be better, larger font and lower case, or what is effectively smallcaps. With regards to the color, it was more about providing a stronger connection between each arrow and its corresponding label - but I can change it so that instead of black and blue, it's black and grey (and thus less contrast). I'm not sure how much smaller I can make it and still have it legible. (Aiiane - talk - contribs) 17:43, 14 March 2008 (UTC)

Sneaking a peak at the upload log, I vote for small caps. - THARKUN 17:57, 14 March 2008 (UTC)

or - other possibilities (naughty peeker you!). (Aiiane - talk - contribs) 17:58, 14 March 2008 (UTC)

for usability reasons: User:Poke/sandbox? poke | talk 17:59, 14 March 2008 (UTC)

Proper alt text on images solves usability without sacrificing look. Edit: I'm also fairly certain that a screen reader would handle alt text better than the triangle character entities you've used. (Aiiane - talk - contribs) 18:04, 14 March 2008 (UTC)

Bah, you are too fast. Anyway, I like the black-grey one with caps alot. - anja 18:06, 14 March 2008 (UTC)

Example with alt text. (Aiiane - talk - contribs) 18:08, 14 March 2008 (UTC)

this may or maynot be a consideration, but i have my monitor setup vertically for viewing webpages. the grey contrast on that is pretty much invisible to me. all i see is black. --VVong|BA 18:12, 14 March 2008 (UTC)

The particular gray I used is fairly close to black (only 30% luminosity). I can adjust it as preferred, if people would prefer a lighter or darker shade. (Only takes a couple of seconds to do that.) (Aiiane - talk - contribs) 18:13, 14 March 2008 (UTC)

(Reset indent) One thing, the style is too "old comp", looks "binary". It looks weird beside our modern looking infobox.reanor 18:14, 14 March 2008 (UTC)

It looks "binary" because it's using a pixel font - there's pretty much no other font that is readable at that resolution. (Aiiane - talk - contribs) 18:17, 14 March 2008 (UTC)

That last one Looks good to me Aiiane. --Kakarot 21:46, 14 March 2008 (UTC)

wow this update sucks... I think its kinda pointless to list the concise desriptions on the skill pages cuz they are just a summary of the normaly description and it looks kinda stupid--The Forsaken One 16:39, 15 March 2008 (UTC)

My little note got lost in this wall of text... I totally disagree with using "Traditional". The longer description is just the normal description. It's not the "traditional" description, there's no tradition involved. Please use "normal vs. concise" or "verbose vs. concise", please don't use "traditional", it's very old-sounding and is making me cringe.

As for formatting... must go for fancy-smhamcy formatting? Can't we do something simple? Just indent the two skill descriptions and put in both "Verbose description:" and "Concise description:"... Seems much simpler and much more straightforward. Hmm... what's that line of Traditional/Concise thingy with the two triangles in it... that's my first impression anyway. Also, I have to agree with the sentiment that the little graphic separator doesn't match the infobox and the skill progression box. -- ab.er.rant 02:15, 17 March 2008 (UTC)

Traditional is the official term given by Anet. Calor 02:17, 17 March 2008 (UTC)

But can't we choose to use "Verbose" instead of "Traditional"? traditional is so ... yucky ... sigh. Since it's official, I guess my opposition won't stand up at all. Oh well. -- ab.er.rant 02:22, 17 March 2008 (UTC)

There is most certainly "tradition" involved - about 2.5 years of it. "Verbose" is not nearly as accurate as "traditional", because in many cases the traditional descriptions are no longer than the concise descriptions. Either way, however, it makes sense to go with the ArenaNet term. (Aiiane - talk - contribs) 20:35, 17 March 2008 (UTC)

[edit] Gray texts in concise descriptions

I was thinking, should we wrap the gray texts in the concise descriptions with a span and a set class (like <span class="additionalInfo">Gray text</span>)? That way we can change the look of it when we've decided how it should look using only CSS. — Galil 21:04, 14 March 2008 (UTC)

Addition: We could also use a bot to change things later on if we do, as the bot would then have something to go by. — Galil 21:05, 14 March 2008 (UTC)

I think it's a good idea. :) - anja 21:20, 14 March 2008 (UTC)

Could even wrap that up in {{gray}}. :P — Galil 21:34, 14 March 2008 (UTC)

Sounds like a good idea Galil, would make it a lot easier to change the look once we have a final decision, although I'm not completely sure what you mean by wrapping it in {{gray}}? --Kakarot 21:46, 14 March 2008 (UTC)

Example from "The Power Is Yours!": Elite Shout. Party members in earshot gain {{gr|1|8}} Energy. {{gray|You have -10 Energy degeneration (10 seconds).}} — Galil 21:59, 14 March 2008 (UTC)

I think using a template makes sense, but calling it "gray" does not. We might well decide to highlight it differently, as already mentioned. This is clever. Please call it {{additionalInfo}} or something more... erm... concise ;) LordBiro 22:01, 14 March 2008 (UTC)

I'd prefer something more precise. -- Brains12 \ Talk 22:02, 14 March 2008 (UTC)

Looks fine to me, not bothered either way. -- Brains12 \ Talk 22:03, 14 March 2008 (UTC)

How about {{extra}} or {{additional}}? (Aiiane - talk - contribs) 22:04, 14 March 2008 (UTC)

Biro suggested {{addendum}}, which I personally like. — Galil 22:06, 14 March 2008 (UTC)

Addendum suggests something that was added later, not something that is in addition to a primary item. I don't really like it, and it's also a less commonly used word (and thus more likely to be confusing to newcomers looking to use it). (Aiiane - talk - contribs) 22:11, 14 March 2008 (UTC)

Agree with Aiiane here - to be honest, gray is fine. I can't think of anything better, and it's not really extra or additional either - it's all part of the description. Gray would even go with {{gr}} in a way. Although, if you want to be really special, go with {{grey}}. -- Brains12 \ Talk 22:20, 14 March 2008 (UTC)

That's what I figured as well. If we have {{gr}}, {{gray}} shouldn't be much worse. — Galil 22:22, 14 March 2008 (UTC)

Gray is not fine. I don't like extra or additional but they are much, much better than gray. I know our templates don't have to be semantic, but it makes a lot more sense not to use the term gray if we eventually decide to decorate additional information with green text or something. Besides, it's spelt grey :P LordBiro 22:23, 14 March 2008 (UTC)

(Reset indent) Actually, my personal preference would be to not format the "extra" grey bits at the end at all. It was done in a partly stupid way in-game, and we don't have to copy that here. Keep it all black, without brackets or extra gibberish, in my opinion. But I guess I'll be content with whatever you all decide. -- Brains12 \ Talk 22:26, 14 March 2008 (UTC)

Just cause we add the template doesn't mean we have to format the text. It's just so we can format it later if we change our minds. — Galil 22:29, 14 March 2008 (UTC)

Well, seeing as I don't really want the formatting anyway, I'm against the template too. -- Brains12 \ Talk 22:40, 14 March 2008 (UTC)

Technically "gray" would still be semantic - it's representative of the text which is gray in-game, no matter how we choose to format it (or not) here. (Aiiane - talk - contribs) 22:54, 14 March 2008 (UTC)

Guilt. I claim credit for putting the grey text in the concise skill descriptions first. ;-) --  (CoRrRan / talk) 00:29, 15 March 2008 (UTC)

I wonder when someone will complain about it being too unreadable... The whole color blindness argument. Calor 00:30, 15 March 2008 (UTC)

I was just about to. Not that it's unreadable, but I personally don't like it. Keep it black imo. -- Brains12 \ Talk 00:31, 15 March 2008 (UTC)

The 'good' thing about a slightly greyish part in that skill description is that people with colorblindness probably won't notice a big difference between that and black, right? Personally, I DO like the greyish part. --  (CoRrRan / talk) 00:34, 15 March 2008 (UTC)

I was thinking people would complain that it would be hard to discern from the white background...but then again, I have good vision. Calor 00:35, 15 March 2008 (UTC)

Well, if you compare grey to light grey, regular grey does stand out from white much more than light grey. --  (CoRrRan / talk) 00:41, 15 March 2008 (UTC)

True. What about darkgrey? Calor 00:44, 15 March 2008 (UTC)

You don't say?! Cor, you make such intelligent statements ;) (My point is, light grey standing out less than grey does not make grey stand out more in general.) - anja 00:45, 15 March 2008 (UTC)

Just tired Anja, I never really re-read what I type... ;-) --  (CoRrRan / talk) 00:50, 15 March 2008 (UTC)

wub :) Anyway, I think I agree with Brains/Pling. Black is both easier to "code" and read. - anja 01:21, 15 March 2008 (UTC)

Ok, my idea: Simply use Normal text.. ''grey text''. If you like we could even change the <i> tag to use a grey-ish color instead of italics.. poke | talk 16:11, 15 March 2008 (UTC)

My vote is for the template, that way we can give it other uses (talk pages, etc).reanor 17:16, 15 March 2008 (UTC)

Why would we ever need a template for gray text on other pages? o.O poke | talk 18:55, 15 March 2008 (UTC)

Because it's fun? -- Brains12 \ Talk 18:56, 15 March 2008 (UTC)

If you want it to be italic my vote still is for the template, so we can change our minds without having to change 2000 articles. — Galil 18:59, 15 March 2008 (UTC)

Please read again, what I wrote. I meant that we use ''text'' in the description and change the i-tag via css so that the text will be gray instead of italics. So we don't need to use a senseless template which make everything complicated and we can still change the style without changing all pages.. poke | talk 19:03, 15 March 2008 (UTC)

Wouldn't that affect the <i> tag on any other pages using it as well Poke? --Kakarot 19:07, 15 March 2008 (UTC)

Not when we do it wise ;) For example when we add an object around the description, we can change all i-Tags within that object without modifying the others. poke | talk 19:10, 15 March 2008 (UTC)

Yes, but what happens when we no longer want it italic? Do we purposely set the i-tag to "text-style: none"? Then for what purpose should the i-tag be there in the first place? We can still style it with CSS if we have the template outputting something like ''{{{1}}}'', except then we can change the tag itself as well, and not just how we want to format the italicized text. — Galil 19:12, 15 March 2008 (UTC)

Fact is that a template will require more loading time. And a text like Elite Shout. Party members in earshot gain {{gr|1|8}} Energy. {{gray|You have -10 Energy degeneration (10 seconds).}} is definitely harder to read than Elite Shout. Party members in earshot gain {{gr|1|8}} Energy. ''You have -10 Energy degeneration (10 seconds).''. And it's not that we use <i>Text</i> but a common MediaWiki syntax which is used to highlight text. That MediaWiki replaces that for the i Tag is not important. And CSS is for modifying those styles. poke | talk 19:15, 15 March 2008 (UTC)

Don't change normal usage of wiki coding on the most viewed pages on wiki (probably). How on earth are people going to learn to handle it then. Apart from the fact that I wouldn't like it italic in the first place and then it seems odd to use the "italic-code". :P - anja 19:24, 15 March 2008 (UTC)

(Edit conflict) So let's say we do it like that. How would you go about if we decide to change the text since we decide we no longer want it italicized. A bot would work, but wouldn't it just be easier to go to {{gray}} or whatever and change it? Also, templates don't increase loading time with the way MediaWiki is constructed. If we edit the template, it "invalidates" the pages that use it, so they get added to the job queue, which means they'll get processed at a decent pace and not hammer the wiki. If we edit the page itself, it's only a matter of one template, which takes probably a whole 0.02 seconds to fetch from the database. I personally am in favor of making it editable in the future as well, in case we want to change something but I don't feel strongly about it to argue. I do however think that refusing to make something easily change-able just for the reason that "it makes things easier to read" is a bad design decision. — Galil 19:25, 15 March 2008 (UTC)

(Reset indent) I don't even get poke's idea, too much code for me, but it looks smart. Still, Galil's right, we use templates for that reason. BTW, whatever it is, it will be part of the skill infobox code right? So there won't be a display like poke described. We'll just add a parameter for the gray text and the template will take care of the font. EDIT: woot, I just solved it. The font code will be part of a parameter of the skill infobox, so we can change it whenever we want by editing the infobox.reanor 22:44, 15 March 2008 (UTC)

Personally I prefer Galil's method, it seems a lot easier to implement/modify and depending on the name of the template it wouldn't add much more code than Poke's suggestion. --Kakarot 03:10, 16 March 2008 (UTC)

No, we won't Ereanor. We would have a parameter "concise description" as we have now where both parts, the normal and the gray text, need to be inserted. So an editor would need to use that formatting for the gray text. My idea was simply to use the existing syntax '' text '' and change that look inside of the skill description so it will be gray instead of italiced. poke | talk 15:58, 16 March 2008 (UTC)

A different parameter for the gray text is way easier to implement and to edit.reanor 16:07, 16 March 2008 (UTC)

I really don't like the idea of overloading the italic. Italic means italic not grey text, grey italic text or text which is possibly identical to the text which precedes it because we've decided not to format it.

From the handful I've looked at it seems that the grey text is used to indicate the limitation of the skill, perhaps indicating the restriction of the skill use. "Easily interrupted", "Cannot self-target", "No effect unless this foe's spell targets one of your allies", "Loose all adrenaline". Perhaps 'lim', 'limit', 'limitation', 'proviso', 'qualification', 'restriction', 'res' would be good template names? --Aspectacle 23:15, 16 March 2008 (UTC)

I don't like the idea of overloading it either. It tends to be confusing to those who weren't in on this discussion. And I have one big question. Why exactly do we need to make it gray? Are we taking on in-game text colors now? It's reminding me of green and red text in the game. -- ab.er.rant 02:04, 17 March 2008 (UTC)

Unfortunately, as I was suggesting, the grey text seems to indicate limitations to the skills ability. Why they've selected to highlight that differently from the other effects indeed seems a bit odd, and to me it does seem somewhat unnecessary. Thus I feel it is unnecessary here.

Of course - the green skill range text is unnecessary too - but I guess I just like it and am used to it that way. :) --Aspectacle 03:33, 17 March 2008 (UTC)

The whole concise descriptions thing is unnecessary, but we are to document all, so here we are.reanor 15:09, 17 March 2008 (UTC)

That doesn't mean we have to do it exactly as in game though, just look at our awesome exhaustion and sacrifice icons ;) My point is, it's better to present it in a good way than doing it exactly as in game. - anja 15:46, 17 March 2008 (UTC)

Wasn't an icon added to Guild Wars recently for sacrifice which looks very similar; if not identical; to the one that was used on this wiki first? Maybe I'm just remembering wrong :\ --Kakarot 16:15, 17 March 2008 (UTC)

Yup - a red circle though, not a red blood drop. --Aspectacle 20:27, 17 March 2008 (UTC)

(Reset indent) My whole idea with the template wasn't so we would change the look of the text, really. It was more so we could change it later if we wanted to. I'm all for having it black, personally. The reason I suggested it was cause when I did, we still had ~1400 skills to add concise descriptions to and no idea of how we were going to reflect it yet. Thus I figured it would be easiest to add a template so we could change all that when (read if) we decide how it should look, before adding the parameter to all skills. — Galil 12:30, 20 March 2008 (UTC)

glory to this wiki. consensus as won and Healing Signet still repeat itself. not knowing what this was about it just(still) look stupid. Anksa 06:25, 24 May 2008 (UTC)

[edit] redundant doubled type mention

(I searched the first three archieves for similar headers, but couldn't find it, so i'll start my suggestion:)
Each skill's type is mentioned twice. Once in the table of the infobox, and once in the skill description. Hence I'd suggest to remove it on the skill description. —ZerphaThe Improver 00:55, 23 March 2008 (UTC)

The skill description is a fixed text from in-game whereas the Skill infobox lists facts about that skill. Also in concise description there is often more precise information in the description skill type, for example "Touch skill" although it is a "Skill". So, I disagree, we should keep it both. poke | talk 01:00, 23 March 2008 (UTC)

Yeah, who cares?reanor 01:30, 23 March 2008 (UTC)

(Edit conflict) i aready suspected that it was mentioned because the ingame skill description does as well. But i wonder why the attribute isn't also mentioned in brackets behind the "main description" then as well. I actually wouldn't say that's a big problem, but I forgot about the supertype "Touch" from the concise description. That causes problems. So well, excuse me, this idea was not the best...i already kept it for a longer period of time in my mind, but coming up with this now after the release of concise descriptions is likely too late... —ZerphaThe Improver 01:33, 23 March 2008 (UTC)

me ;) but as mentioned, implementing of this idea is now rather unlikely...unless someone comes up with a amzing new idea how to prevent this dupplication in another way. —ZerphaThe Improver 01:35, 23 March 2008 (UTC)

idea: delete all skill articles? - ok, forget about this section :P poke | talk 01:53, 23 March 2008 (UTC)

<irony>better idea: merge all skill articles with the main article and divide it into sections!</irony> —ZerphaThe Improver 02:07, 23 March 2008 (UTC)

Touch works more as a range than a type of skill. Probably skills look in lists, not in skill types when they seek skill conditions like it being a touch or a spell. That's why sometimes bugs appear when a spell is not interrupted or a skill triggers an effect after having its type changed. The description is not a definite way to know things about a skill. Testing it is. MithTalk 02:11, 23 March 2008 (UTC)

Aye, the desciption is just a text string, and can be wrong. Sneak Attack for example. Backsword 06:33, 23 March 2008 (UTC)

[edit] Skill sounds

← moved to Guild Wars Wiki talk:Projects/Skill sounds

[edit] ID

If we add this to the parameters of the infobox, do we actually display it? I don't think it's something most players care about, it's really only of interest for people interested in background stuff. Backsword 11:21, 28 March 2008 (UTC)

I think a small play icon (generic triangle in a circle in a square no bigger than the skill icon itself) would suffice. Perhaps a "show" "hide" option as well? --People of Antioch talk 15:31, 28 March 2008 (UTC)

Text can also be hiddeng by making it have the same color as its background... but that it not very wiki-wise. I think a good option would be to make it a little gray text in a corner something noticeable if you look for it, but not looking as important data. MithTalk 15:46, 28 March 2008 (UTC)

Adding a hideable something or hide the text by making it white is a stupid idea. We don't have to show the id in the infobox to store it. But I would like to see a greyish "#123" in the lower right corner. I think that would look good :) poke | talk 18:17, 28 March 2008 (UTC)

[edit] skill tables/lists and concise

i know it's been mentioned before, but do we want to make the skill tables display concise descriptions now or leave it the way it is? i wanted to test it out in my sandbox, but i realized i didn't understand how the skill infobox.row template was called. --VVong|BA 16:24, 28 March 2008 (UTC)

It's called by Template:Skill_table where it has the text "{Skill infobox}.row format". This is DPL's way of specifying both Skill_infobox as the part to pull data from and Skill_infobox.row_format as the way to display it. To test things separately, you'll need a new template with a name that starts with "Skill infobox"; maybe you could reuse Template:Skill_infobox.dpl which I think is only still around from old testing. --Rezyk 17:19, 28 March 2008 (UTC)

Never mind. I changed Template:Skill_table to use Template:Skill_infobox/row_format by default, and also to accept an "inner format" parameter to specify a different one to use. So you can add "inner format = test format" to any Skill_table call to see what concise descriptions would look like. --Rezyk 17:58, 28 March 2008 (UTC)

thx. i tried it out and it didn't seem to affect my scroll time much. i was gonna see if that would a justification for going to concise, but it looks like the benefits of concise will not depend on shortened scroll time. if we go to concise for skill tables, it will be b/c of benefits in other areas. --VVong|BA 19:48, 28 March 2008 (UTC)

[edit] Related skills

So, based on the constant differences in interpretation, the notes describing the section, and the role/function discussed at Guild Wars Wiki talk:Formatting/Skills/Archive3#Related skills - what's our goal ?, I changed the "Related skills" name in this guideline to something that I feel is less perpetually confusing. --Rezyk 18:22, 15 April 2008 (UTC)

Actually I think it is quite more confusing as you for example cannot easily substitute a skill with another elite skill.. I think the current section title is a lot easier to recognize and fits more to what skills are actually listed in that section. poke | talk 18:28, 15 April 2008 (UTC)

But that's why it's potential substitutes rather than easy substitutes. I agree that "related skills" does fit some actual lists better (like Verata's Sacrifice being "related" to other skills named Verata's), but therein lies the problem with the desired identity of this section. --Rezyk 18:37, 15 April 2008 (UTC)

We've had alot of disputes lately over what goes into that section and what doesn't, so I think a change or clarification is needed. I'm still not clear over what the goal is with it. Do we list skills like "if you like this skill, that skill is almost identical", or "if you like this skill, this skill also involves knockdown in some way", or what? The discussion before was more about not listing monster skills with player skills, iirc. - anja 19:19, 15 April 2008 (UTC)

And I think the current listings are quite good and there is no problem with them (at least as far as I noticed), so I don't think we need to go through 1000 pages to change that heading. poke | talk 19:28, 15 April 2008 (UTC)

I see mainly two types of relation:

• Funtionality. In this case, we should put player skills in both player and monster skill pages, but monster skills only in other monster skill pages. The skills put are skills that behave in a smilar way, being of the same type and having similar effects, and special skills that are activated in a similar way, like all the "increase speed in outpost" effects(sugar rushes), that are activated by using sugary items.
• Lore. In this case, we put skills that have similar names (Verata skills), skills related in place (Real of Torment environment effects) or skills related in game plot (Mist and and Orr scepter effects)

So what is what we never do? Putting any non-player skill in player skill pages. MithTalk 20:52, 15 April 2008 (UTC)

This would miss out on much current usage that I find useful: Listing skills that you can't substitute with in a build, but whioch could achieve the same (well, simillar) effect in anotrher build. (eg, different primary). People may be comfortable playing one prof., or even one ele line, but want help when switching to a new. Backsword03:00, 16 April 2008 (UTC)

I'm not seeking to exclude those, I just want the section name to better match its identity. It seems that you interpret the meaning of "substitute" much more strictly than I do; for me, one could naturally switch primary professions and use skill X of the new profession as a substitute for skill Y in filling function Z of the build. (Does this meaning not make sense?) --Rezyk 00:47, 18 April 2008 (UTC)

That's how see it as well. Since there's confusion as to what it should be, why not just split that section into "Similar skills" and "Related skills". Then the former will list skills that are functionally-related or functionally similar (while not necessarily "substitute-able"), and the latter would be for lore relations. -- ab.er.rant 03:31, 17 April 2008 (UTC)

What about "Similar or related skills" then? :P Would remove the need to go to all skill pages and deciding between both sections :P poke | talk 14:34, 17 April 2008 (UTC)

beyond taking monster skills out of player skill relations, is there really a need to change the wording? the two words can almost be used interchangeably anyways. will a person reading the page for the first time understand what similar vs related means in the context we're talking about? --VVong|BA 14:56, 17 April 2008 (UTC)

This still doesn't solve the problem if Brace Yourself! is related to Aura of Stability or not. Do we want to make a clearer guideline what to list, or leave it up to lengthy discussion for each case? (Not saying one option is better than the other) - anja 15:15, 17 April 2008 (UTC)

1. I don't think it's possible to control what people put in this section by finding that just right name, unless we make it essay lenght. So changing sectuion name is wasted effort. I've reverted that.
2. When it comes to Lore, I think the trivia section is better suited for that. The example given, with Verata, should link to Verata more than to other skills named after him. I think that rule can be made general.
3. I think we need a seperation on skills that are similar in usage, and those that has some aspect that works with the same game mechanic but are not otherwise similar. Eg Signet of Judgement and Shield of Judgement.

Backsword 11:16, 27 April 2008 (UTC)

[edit] Skills with separate PvP versions

I think that these should be given separate articles so that both versions get entries in the DPL tables. I think that PvE and PvP versions of dual-version skills should be categorized with the special parameter in the infobox, with PvE versions of dual-version skills getting a separate category from PvE-only skills. I think we should go with <skill name> and <skill name> (PvP), since the PvP versions will have PvP in brackets after their names in-game. -- Gordon Ecker 04:19, 10 May 2008 (UTC)

No clear thoughts on this, but I do think it would be nice to be able quickly see the differences. But depending on how many there end up being, and we won't even know that initially, it may just be better to create a cross reference table with PvE and PvP version and do like Gordon suggests for skill pages. So hard to know because we can't know what will happen. A skill could end up having a different version and then later could go back to only the one version, and we wouldn't