Guild Wars Wiki talk:Formatting/Skills/Archive4

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)

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)

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)

Skill sounds

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

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)

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)

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)

I had to make a little change. It din't make sense to add two skills with similar names, both offering burning with two different mechanisms (one directly, one triggered by an hex) and then telling that two skills with similar names can't be related if they both offer knockdown, but with different mechanism (one directly, one triggered by a foe attacking the target). There is one clear reason why the Rodgort spells are related, and it's the Rodgort trivia. They are both "Rodgort spells". Same goes with other skills related by lore or trivia, like the different effects you may suffer while in the Torment(I think many of them are already related, and there is no other reason other than proximity in lore), or the Different skills named after the same person, like Verata, Teinai, Xinrae or Zojun. MithTalk 00:55, 16 October 2009 (UTC)

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 want two diffent pages then which would imply that they were actually different. So maybe best would be separate listing in DPL tables, but only one article that they would both link to if a PvP version exists. -- Inspired to ____ 04:55, 10 May 2008 (UTC)

A single article with two entries would be ideal, but I'm not sure if DPL could handle it. -- Gordon Ecker 05:11, 10 May 2008 (UTC)

(Edit conflict) I concur with Gordon. Besides the DPL benefits, skill pages would be a mess if we tried implement information for both PvE and PvP versions on one page: traditional and concise descriptions for each and separate progression tables would be far too much clutter, and I don't even want to ponder what if they have different energy/activation/recharge. A simple disambiguation thing at the top can let people know that the other version exists, and we can always {{historical content}} and decategorize the PvP skill pages if they remerge with the PvE version. - Tanetris 05:14, 10 May 2008 (UTC)

What's the easiest way to also list them on a cross reference table. Thinking maybe a separate category for dual version skills. -- Inspired to ____ 05:29, 10 May 2008 (UTC)

I agree with Gordon and Tanetris that there should be two separate pages, though I don't see a valid reason for not categorizing the PvE versions as PvE only, since they are. As for a cross reference table, I think that might be better worked out once we know what kind of skills and what kind of differences we are looking at. -- Wynthyst 05:50, 10 May 2008 (UTC)

My thinking is that what will be of most interest to the most people right away when this happens is what skills now have two versions and what are the differences. Hopefully, we can count on ANet to provide that in a concise and useful manner, but I'm not sure we should bet on that. Other than that we will indeed have plenty of time to set up after the change. -- Inspired to ____ 06:11, 10 May 2008 (UTC)

I think they should get a separate category because, unlike PvE-only skills, the PvE versions of dual-version skills will almost certainly be usable by heroes and not count against the 3 per bar limit of PvE-only skills. -- Gordon Ecker 06:28, 10 May 2008 (UTC)

I agree that the pages should be seperate, and possibly making 2 new categories for them? --Shadowphoenix 06:35, 10 May 2008 (UTC)

Ah.. good call Gordon, I wasn't thinking in those terms. So maybe we make a new category Category:Dual skills, and 2 sub categories, Category:PvE and Category:PvP-- Wynthyst 06:38, 10 May 2008 (UTC)

Yeah, I like that idea better Wyn --Shadowphoenix 06:42, 10 May 2008 (UTC)

(Reset indent) I am not sure if separating them would be a good idea, since people already were complaining when this idea was proposed long ago that they would have problems keeping track of all the variants for each skill (but again, people complains because it's thursday, because there is fish for lunch, and because the answer is 42). Maybe we should wait and see how they implement the change (which i would guess it will be like a new description a-la concise when on pvp), and try to find a good way to integrate all the information so it's easier to find, instead of having to separate and forcing users to check more than one page when checking skills for a PvX build, by example (i mean, there MUST be people out there that doesn't use cookie-cutter builds, right? right?).
About the other... yeah, a new category is a fact already. I don't think there will be too much need for discussing that.--Fighterdoken 06:44, 10 May 2008 (UTC)

I think the inclusion of a cross reference table on both pages as Inspired mentioned would ease some of that.-- Wynthyst 06:48, 10 May 2008 (UTC)

Imo it depends on what differences are between PvE and PvP versions of Dual skills. When they only differ in the progression, it would be better, to have it only on one page. But I think that ANet will take the chance to reword some skills also, so two articles would be easier.

We could then include a link to the other-side Dualskill so that you can easily switch between both. And for a cross reference table it would be possible to have PvE description on the left and PvP description on the right to compare. poke | talk 13:27, 10 May 2008 (UTC)

If there's only a difference in the green numbers, I'd go for having it in the same article, we can have a special progression table made so it looks neater. But as soon as something else is changed (wording of description, recharge/activation etc) I think a new article would be better. It would be really hard to present it in a way that's easy to understand if we keep it to one article, I think.
I'm not sure if I like the "dual skills". Would "Split skills" or something like "Skills with two versions" work? - anja 14:00, 10 May 2008 (UTC)

I'm not a fan of "Dual skills" either, as it reminds me too much of Dual Attacks. I like "Split skills". Also, we would be making separate articles, as I can almost guarantee you that there will be changes in skill mechanics, not just values. On a small last note, would it be over the top to redirect, say, "Light of Deliverance (PvE)" to Light of Deliverance? And the same with, say, "LoD (PvP)" to "Light of Deliverance (PvP)"? Calor 15:17, 10 May 2008 (UTC)

A bit late but separate articles would probably be better since it's likely that there will be more changes than just the green numbers. Also Category:Split skills works for me although something like Category:Skills that have now got both a PvP and PvE version so skill balancing is easier and also need to be placed in a category with a really excessively long name for no apparent reason just to make the longest category name in the entire wiki could also work :P --Kakarot 15:27, 10 May 2008 (UTC)

Unlike the Kurzick/Luxon skills, which are completely the same, changing the icon, and the Copycat skills, that just change name, icon and campaign, it has been arleady told that PvP skills will have separate ID numbers and different names, by adding (PvP). Since skills are usually visited from the game using the Links in the F10 Help Panel, the best option would be to make separate ones. Not only the descriptions would be different, the Notes would be so too, since they use would be different in PvP and PvE. Of course, in both pages there should be a very visible link to each other versions and a warning: "This skill has a PvP version", "This is a PvP version of another skill". MithTalk 18:06, 10 May 2008 (UTC)

"Unlike the Kurzick/Luxon skills, which are completely the same, [...], it has been arleady told that PvP skills will have separate ID numbers [...]" - to be correct there, Kurzick and Luxon skills are not the same. They are handled as unique skills within the game, so they have an own Skill id. poke | talk 18:23, 10 May 2008 (UTC)

That was not my line of thought. They will have separate effects, and since they have searate IDs, they can be linked separately in the Help Panel to two different pages. Like those Luxon/Kurzick where linked to the same page, and copycat skills where linked to separate pages. The point is that their functionality will be different enough to deserve separate pages.MithTalk 18:27, 10 May 2008 (UTC)

To be brief, I like "Split skills" and I'd prefer page splits on a as-needed basis. -- ab.er.rant 05:29, 12 May 2008 (UTC)

Personally i prefer page separation cause the new numbering in pve may synergy perfectly with some skills, but not with the pvp version of it. Thus will make the notes confusing. Example Shadowform can be kept up in PvE if u use QZ and SQ, but it will not work on its PvP version. Also there may be a total mess in the talk page, as in whom is talking about which version, --MageMontu 19:51, 21 May 2008 (UTC)

Oo..I came so close to editting Category:Skills that have now got both a PvP and PvE version so skill balancing is easier and also need to be placed in a category with a really excessively long name for no apparent reason just to make the longest category name in the entire wiki just so that page could exist.... I'm more professional than that. I like the split skill category, as well as separate pages. Would probably be best to have a link to the other version of each skill on each page, however. That might even go without saying. Mohnzh say what? 20:10, 21 May 2008 (UTC)

Now that we're real close to this, do we just follow ANet's lead on the Developer Updates with whether the new skill is PvP or PvE, or do we just create all new ones as PvP versions. I believe it will affect talk pages, history and links on other pages whether some are moved to the PvP version and PvE version recreated or PvP versions are just created new. -- Inspired to ____ 20:34, 21 May 2008 (UTC)

I'd probably make for less confusion if we had the all of the new pages as the PvP ones, just to prevent confusion of discussion with PvE-only skills. (Aiiane - talk - contribs) 20:39, 21 May 2008 (UTC)

To stick to the in-game naming, we should have Skill name for PvE and Skill name (PvP) for PvP. poke | talk 20:43, 21 May 2008 (UTC)

Right...my question was only how we get there. But, I agree with Aiiane that it would be better to be consistent then to try to base the changes on what is happening. The other advantage will be that a user won't need to know whether the change was made on the PvP or PvE side to get to the history, they can just always go to the PvE version. -- Inspired to ____ 20:56, 21 May 2008 (UTC)

We could change the skill infobox template to make an automatic link to a PvP-version page if parameter PvEversion=y and another automatic link to the PvE version on the PvP-version page if PvPversion=y. That might be easier than manual links. 145.94.74.23 06:16, 22 May 2008 (UTC)

I'm not sure about automatic linking to the PvP version would work. If not, we'd just need to manually enter the skill name. -- Gordon Ecker 06:41, 22 May 2008 (UTC)

The skills are so few now we could as well enter a {{otheruses}} manually on them all without much work. We have the problem with the article/skill name, as Gordon says, if we are using the infobox to do something automatic. - anja 07:17, 22 May 2008 (UTC)

Another option could simply be to create new pages for the (pvp) skills as they get seperated through updates. It wouldn't be that hard, just copy over the information from, say, "Incoming!" to "Incoming!"(PvP) and adjust the variables accordingly. Silavor 22:41, 22 May 2008 (UTC)

...That's basically what was said through most of this discussion. - anja 22:52, 22 May 2008 (UTC)

(Reset indent) For some reason the PvP versions are showing up in the skill tables as an additional skill, but are dropping the "(PvP)" from the name. -- Inspired to ____ 23:10, 22 May 2008 (UTC)

Because of the "name" parameter, I think. It might need to be adjusted. I didn't do anything to it when copying since I don't know which way people will want to have it. - anja 23:11, 22 May 2008 (UTC)

Probably it will be needed to add a hidden parameter to the skill infobox for pvp skills, so they can be filtered (or re-named?) when displaying lists...--Fighterdoken 23:15, 22 May 2008 (UTC)

(Edit conflict) Okay...this way make tables look cleaner but only way to see which is which is to mouse over. -- Inspired to ____ 23:18, 22 May 2008 (UTC)

In the same topic (and since this was brought in the update talk page), should be upload the images for the pvp versions also, even if they are just the same as the pve versions? (pro and cons in the link).--Fighterdoken 00:26, 23 May 2008 (UTC)

Might I suggest instead of adding a parameter, we simply use a slightly modified infobox (a la {{Pvp skill infobox}}) for PvP skills - not only does this allow us to avoid uploading skill icons twice, it also means that we can easily explicitly include or exclude PvP skills from lists. (Aiiane - talk - contribs) 03:04, 23 May 2008 (UTC)

I have no problem with having a seperate infobox for the PvP version, however we would probably still need to reupload skill icons for the PvP versions for redirect reasons. --Kakarot 03:10, 23 May 2008 (UTC)

By definition an icon should lead to a specific page when clicked on...this requires a unique icon for every unique page or it's not really an icon. -- Inspired to ____ 03:13, 23 May 2008 (UTC)

Nevermind anyways, I thought of some other issues that would come up as well. I've still left the 'has-pvp' attribute in {{skill infobox}}, but I'm getting rid of {{Pvp skill infobox}}. (Aiiane - talk - contribs) 03:49, 23 May 2008 (UTC)

I would really like to have a table of just skills that have a PvE and a PvP version and I'm thinking that attribute would work to build it. Now, if I just knew what I was doing. -- Inspired to ____ 03:55, 23 May 2008 (UTC)

Please no second infobox. As soon as I have time today, I'll try to finish the skill infobox proposal me and Anja were working on; including something for split skills. poke | talk 09:49, 23 May 2008 (UTC)

There is no need for a second infobox. The current one would do. You only has to set the 'special' property with the following options:

PvP. The skill is a PvP-only skills with a PvE counterpart.

PvX. The skills is a PvX skill that works the same in PvP and PvE.

PvE. The skill is a PvE-only skill.

PvEcopy. The skill is a PvE counterpart of a PvP-only skill.

PvEplot. The skill is a special skill available only during a certain mission or quest.

Monster. The skill is a monster skill.

Environment. The skill is an environment effect not activated by a selectable creature.

Bundle. The skill is activated by holding or dropping a bundle (excepting ritualist bundles, of course).

Item. The skill is activated by using a consumable.

Something like that would be more than enough. There is no need for more skill infoboxes, not even effect infoboxes. MithTalk 13:52, 23 May 2008 (UTC)

(Reset indent) As you may or may not have noticed, I already tossed out my own idea re: a second infobox. Also, {{skill infobox}} has already had "has-pvp" and "is-pvp" attributes added and all of the skill pages for concerned skills are updated to reflect that. (Aiiane - talk - contribs) 15:34, 23 May 2008 (UTC)

A second infobox would require recoding of all skill DPL lists, and some duplication of templates that makes those lists work, while tweaking the current infobox doesn't require as much work. So I'd like to keep the old one for pvp skills too :) - anja 15:50, 23 May 2008 (UTC)

Arg, how many times do I have to say I already realized all of this and that I'm not longer suggesting such a thing? Seriously. >< (Aiiane - talk - contribs) 15:52, 23 May 2008 (UTC)

Sorry, only really read your last statement, where it sounded like it still was your suggestion. I should read it all and not just the last one ;) - anja 15:58, 23 May 2008 (UTC)

I understood that you already forgot about that idea, but as we have people here, who suggest something which has been set 20 comments before (*looks up*), I just wanted to say that again :P Also the link was still blue when I wrote it. poke | talk 17:14, 23 May 2008 (UTC)

Suggested boss capture.

Ive been going through the Elite Skills titles. Ive been using the Wiki to find the locations of each boss. One thing that I think would be very benefitual to have the easiest boss to capture and elite skill marked on the elite skill page. this way a player can just pop up the elite skill and instantly know witch boss he/she should go for. ~ Zero rogue x 00:39, 20 May 2008 (UTC)

The problem is to determine which one is easier. One boss may be easier for one player but harder for another. Of course, there are really simple cases, but they are so few I don't think we would need to include this in the formatting. I'd say we could just include a note about it (in notes section?) in those cases where it is obvious which one is easier. - anja 07:11, 20 May 2008 (UTC)

I also think that what's "easiest" is subjective. Can you give an example? I'm having a hard time seeing what you mean. You mean instead of having to click on the names of 2 or 3 bosses, we just put a little marker there that essentially says "cap from this guy"? -- ab.er.rant 07:34, 20 May 2008 (UTC)

This sounds like something that would be better as simply a personal note on the talk page. (Aiiane - talk - contribs) 07:45, 20 May 2008 (UTC)

IMO the most important capture-related issues for most players are when the skill first becomes available in each campaign or expansion and which other skills can be captured in the same run, both of which are covered by list of elite skills by capture location covers. We could add region information to the Signet of Capture entry, but, as others have said, "easiest" is too subjective. -- Gordon Ecker 08:01, 20 May 2008 (UTC)

Ab.er Said it best Something that allows players to just go through Each elite skill and find whatever boss is easiest to cap.(we could even put this on its own page.) As for which one is easier, I have found that nearly all the skills have one boss Obviously easier than others. Take into consideration the Skill Cleave, as it is a core skill it is capture-able in all campaigns, giving it 10 bosses to choose from. Now if you look at each boss many of them are half way through the map. That is until you reach Razorfin Fleshrend who is nearly right outside the portal, an obvious choice for anyone wanting to capture cleave. However in our current system someone would have to go through each boss in order to find the Simple boss. As for the one that are a tie between Theres no reason we cant just put a icon on both saying there both the same difficulty. Gordon, IMO Location only matters down the campaign. from there I always go in order By Profession. Although Location is nice, it's pretty useless when you can only capture at max two different professions. Also the larger problem with a capture locations list is the ability to ensure you get all the skills. there is the chance you miss some when they don't pop up in any locations you want them in, however thats off topic. What I would like is an icon (probably a small picture of the capture signet) next to the name of the easiest boss to capture. I Have been going through each elite skill title, currently finishing elona to make a complete set. I can say from my experience that a single icon would make my and many others' boss hunt a walk in the park. ~ Zero rogue x 10:40, 20 May 2008 (UTC)

It's too objective to say that. PEople should see the maps, see the areas they are in and decide themselves, we give info and tips, not things in a silver plate. MithTalk 12:52, 20 May 2008 (UTC)

I have to agree with the others, the easiest to capture is too subjective and what's easy for one person isn't necessarily easy for another. Also in my experience the easiest isn't always the one closest, I can't remember which bosses/elite it was but there were two locations to get the elite skill and the one that was farther away I found easier, I think it may of been because of the bosses skill set in comparison to my own/my teams as well as my teams professions. Also I agree with Gordon about the most important capture issue. I would prefer not to include something like this for these reasons since I'm sure there are a number of people who have played for a long time/had a lot of experience with elite skill capturing that would disagree about which is easy and which isn't. --Kakarot 13:21, 20 May 2008 (UTC)

While Zero's idea is fine, rather than using "easiest", we could say "nearest to an outpost". The problem is in finding an icon that's suitable for it. I don't think any icon correctly conveys that idea. Instead of marking each elite skill article, would a variation of the list Gordon mentioned be helpful? So that instead of listing elite skills by location, we list location+boss by elite skill, sorted by relative/estimated distance (or just list one). -- ab.er.rant 02:58, 21 May 2008 (UTC)

While that is closer to objective, there is still issues such as campaign ownership, and quest bosses. Can't just assume everyone has all the campaigns. Or all quests available. Backsword 05:01, 21 May 2008 (UTC)

Why not? We can put in an explanation at the top of the list, explaining that the list assumes that all campaigns are accessible and all bosses are sorted by their proximity to an outpost. If it doesn't look cluttered, we might be able to add icons or indicators to mark different campaigns. We could also create multiple such lists. -- ab.er.rant 05:55, 21 May 2008 (UTC)

List? Are you talking about creating a seperate article for this? I'd have no problem with such an article, cluttered or not, as people could just avoid it if they wanted. Backsword 06:08, 21 May 2008 (UTC)

Yep. As an alternative to having icons on all the skill pages, I was suggesting to create something like List of elite skills by outpost proximity or something. -- ab.er.rant 06:41, 21 May 2008 (UTC)

this isn't a systematic means of documentation by any stretch, but i've found that the wiki already has something close to this. the objectively easiest boss caps are pretty much the only bosses that have a location map. i'm not saying this is good documentation and should remain this way. just noting an observation. --VVong|BA 14:41, 21 May 2008 (UTC)

That's completely normal. In any wiki, the most interesting articles and pieces of information are given more attention that the less ones. So the a boss is visited, the more information its article will have. MithTalk 17:11, 21 May 2008 (UTC)

Forms and Disguises

These skill types are notable as each is associated with a specific model they switch the user to. I think it would be helpful is skill pages actually displayed these, preferably in some form of standarised way. Backsword 21:30, 18 June 2008 (UTC)

Skill updates

Should we add a link to the last update which changed a skill to the skill inobox template? What about adding subpages for skills' full update histories? -- Gordon Ecker 02:27, 17 September 2008 (UTC)

Starting from now? Why not? I would like to make comparisons much like the "diff with current policy" links. It makes things easier to track and predict and view trends. --Antioch 03:50, 17 September 2008 (UTC)

The last update link on the infobox is brilliant :D I previously suggested for either a "History" section or a "Change history" subpage. -- ab.er.rant 08:24, 17 September 2008 (UTC)

Mark of Rodgort/Skill history serves as an example of a merge between the two; instead of just linking the updates, it says what the update did to the skill and records all of its previous versions. Pages like that could be linked in the infobox if necessary. A good idea, in my opinion. -- Brains12 \ talk 19:46, 1 October 2008 (UTC)

I agree, I think this is a really good idea. And a huge project. :P - anja 19:54, 1 October 2008 (UTC)

Concise descriptions all over again :P -- Brains12 \ talk 19:56, 1 October 2008 (UTC)

Wait for next big balance update? Take off some of the work... calor (talk) 20:07, 1 October 2008 (UTC)

Infobox idea makes no sense. Why have a random trivia fact in an area where users look for info on the skill? A history note in the trivia section seems more in line witrh the rest of the wiki. I'd prefer a clean and simple table over a subpage. I know editors like fancy formating and big projects, but it doesn't actually help in readers's information gathering. Backsword 14:24, 4 October 2008 (UTC)

I prefer the full sub-page. Update notes are not always clear, after an update I often find myself going to skill pages and diffing to see exactly what changed. That example page is exactly what I would want and exactly what I would find useful. It also helps in sorting through historical information for skills that didn't operate in the form they do now that I didn't have or use previously. Misery 12:24, 8 October 2008 (UTC)

I'm going to do this project. -- Halogod35 15:25, 23 September 2009 (UTC)

Skill Animations

I have always wanted to record the skill animations and make them available on the wiki. It was discussed merging this idea with other projects, but in the end that didn't really work out; so I would like to begin working on the skill animations myself. The simplest way of doing so has been by making animated gifs from recorded videos. I would like some opinions on how you people would like the gifs to be - there's a choice between image "size" (how large the image we see is), image "weight" (how many kbs it has) and image quality. Here are some preliminar works:

• Image 1: large size, high quality, but heavy image.
• Image 2: high quality, light image, but small size.
• Image 3: large size, medium quality, medium weight.
• Image 4: large size, slightly worse quality than previous image, slightly less weight.

(For the records, I'm not planning on adding those images to the skill articles, just to link them. If people don't want me to link them on the articles themselves, I would be ok with just linking them on the talk pages.) Which of the above do you people think is better, and why? Erasculio 00:24, 8 October 2008 (UTC)

First off, I know nothing about compression, so there might be a better (read: smaller size) way out there to get the same quality. Second, all of them are to large to include in skill pages, the bigger ones to large by far. And thinking about having a page where all of them are displayed together for comparison makes my internet connection cry. That being said, since the images are going to be "out of the way", I dont see a big problem with going with the best quality. --Xeeron 18:49, 8 October 2008 (UTC)

If you make them somewhere with one single color in the background (like a desert, the Fire Islands or snow) you'll get better results with compression. The best choice would be somewhere with a completely black background. MithTalk 13:32, 9 October 2008 (UTC)

One problem is what to do about the skills that require a target. I'm thinking about using the dummies at the Isle of the Nameless, but then we still have plenty of options for where to take the pictures, and in which angle to do so. Here are some tries, let me know which point of view you people think is better:

• Side view from the left at the row of armor dummies.
• Upside view at the row or armor dummies.
• Side view at the middle of the dummies grid.
• Back view at the middle of the dummies grid.
• Front view from the left at the middle of the dummies grid.
• Side view from the left at the border of the dummies grid.
• Side view from the right at the border of the dummies grid.
• Overhead view from the front at the border of the dummies grid.
• Overhead view from the back at the border of the dummies grid.

Erasculio 01:59, 10 October 2008 (UTC)

You can always ask a friend or a fellow Wiki member. If you see me online, you can ask me to go somewhere dark to take some pictures. I can go anywhere and have all skills. MithTalk 13:34, 10 October 2008 (UTC)

Technical notes: There is .png version that can do animated form, which would be preferable. However, I don't know how good browser support is.

Also, you can use texmod or other software to make the background solid white, blur or black. (or whatever) in order to get cleaner caps. Backsword 00:48, 12 October 2008 (UTC)

APNG is not an option. poke | talk 08:40, 12 October 2008 (UTC)

Yeah, according to Wikipedia's APNG article, the only major browsers which currently support the format are Firefox and Opera. -- Gordon Ecker 09:18, 12 October 2008 (UTC)

Why, that's all of them, init? Backsword 05:37, 13 October 2008 (UTC)

Yeah, APNG isnt gonna be useful till IE at least adds support. Also, it would depend on where they are hosted, or how much space is avaliable there, but we cant have them stupidly big as it would be too slow.Iyatos 09:48, 12 October 2008 (UTC)

(RI) All dervish skills have been made into .gifs. Image sizes go from 0.7 mb to 4 mb, as I went for highest quality as suggested above. For those with fast connections, you may see thumbnails of the skills here and on the albums linked there. The last thing to be settled is where would you like the images to be. IMO, the options, from less to more obtrusive, are...

1. A link in the skill talk pages: the least obtrusive option, it would not change the skill pages themselves in any way. The main problem is that only those who know the animations are there would actually seek them, and we would risk losing the animations in the middle of long discussions.
2. A link in the Notes section of the skill pages: it would require a change to the layout of the skill pages, as it would add one more note, but a small one. The link would be visible and easy to find, without the risk of being lost. IMO, this is the best option.
3. A still frame linking to the full image, as seen for the dance animations: it would require a considerable change to the layout of the skill pages, cluttering them a bit. The links would be very visible and so very easy to find (perhaps a bit too much?). It would also increase a bit the loading time for the skill pages.
4. Directly showing the full image on the skill pages: if we wanted to fry people's connections.

What do you people think? Erasculio 16:19, 22 October 2008 (UTC)

I'd prefer the still frame, but if its too much work changing the layouts then a link in the notes section would be the next best. It would be pretty easy to miss it though, which is why i think the frame is the best idea.Iyatos 17:36, 22 October 2008 (UTC)

I'd also prefer the still frame as shown on the Chocolate Bunny article although as was mentioned this could require considerably more work than a simple link under notes. Another option which we could use is to have the link directly in the infobox, maybe at the bottom using colspan="2" although I'm unsure if this would be a viable option it is more noticeable without much need in modifying the formatting of the actual skill article. --Kakarot 18:18, 22 October 2008 (UTC)

I'm jumping right in the middle of the discussion, but it seems this user has recorded a animation. It seems to be small and clear enough. What y'all think of it? ~ Kurd 23:44, 22 October 2008 (UTC)

It's different from what we're trying to do here, though. He aimed at the character animations - showing how a paragon looks when using a random chant, for example. I'm aiming at the skill animations - what each skill looks like, highlighting the small differences such as how the animation of Radiant Scythe differs from the animation of Zealous Sweep. While showing character animations, details are less important; but when showing the skill animations, details is most of what is being shown. Erasculio 00:16, 23 October 2008 (UTC)

Yes, its not exactly the same point, they are a bit too small to see some small details. Although, as i think someone said above, using texmod or something to remove the background might be a good idea, it would make it more consistent, and easier to see those tiny details.Iyatos 08:53, 23 October 2008 (UTC)

There are some black backgrounds in the game, which I have found thanks to other players (example: 0.8 mb image). For the assassin skills I'm avoiding that background because mine has black armor, and so we lose a bit of contrast - I'm using this background (0.5 mb image). For the other professions, all skills that target self or that target an ally may be taken under that background. The main problem are the skills that require a hostile target, which so far means using the dummies at the Isle of the Nameless. Erasculio 18:43, 23 October 2008 (UTC)

Anet and this project

I did a little digging around and found the personal website of Brant Fitzgerald, the one making all these animations. He put up a video of some animations. Which means that he can somehow view and record them much easier than we can. Download the video here so we don't overload his site. Maybe if we ask real nice, he can help us out ~ Kurd 21:00, 24 October 2008 (UTC)

Nice, great find. I wonder what are the skills being shown in that video, I can only identify a few of them. Erasculio 21:17, 24 October 2008 (UTC)

(RI) Emily has mentioned on her talk page that Brant Fitzgerald has left Arena Net, so he won't be able to help us with this project. She also mentioned how right now they don't have resources to capture the animations for us, so I guess this is really a job for our community : )

I liked the idea of adding links to the skill animation in the skill infobox. This could make the implementation of the animations easy, as it could likely be automatized (with a "<PAGENAME> Animation.gif" link?), instead of requiring us to manually add links on every skill article. But I don't have enough knowledge about how the skill infobox to make those changes myself...Do any of you know how this kind of change could be made, or if it could be done at all?

Making still frames to be used as links isn't hard at all. If that's what consensus prefer, it could be done easily, although we would still have the problem of where would the images be placed, within the skill articles (maybe in the skill infobox?). Erasculio 13:27, 25 October 2008 (UTC)

A community job... this should be interesting. If we all really do want to make animations, then we'd need to set up a project and guide for it, for starters. All it would take to add (a link to?) the animation in the infobox would probably be a line or two of code with, as you put it, "<PAGENAME> Animation.gif". We would simply need to make sure all images were uploaded with proper naming (GWW:PR/II did it perfectly, with a preset list. Click and upload). I would prefer having some sort of built-in player with the option of playing the animation if desired; although, it seems that might create serious strain on the servers and on viewers' computers. If not, I suppose an external link of some sort would suffice. calor (talk) 15:53, 25 October 2008 (UTC)

Use "<Pagename> animation.gif" then please (lower-case "a") poke | talk 16:20, 25 October 2008 (UTC)

I had made a very very simple guide here. I'm waiting a bit so we know how to implement the images before making a full project, so we could show people the final result on the skill articles when asking for their help. Erasculio 16:26, 25 October 2008 (UTC)

Two issues:

1. I have made a test to see what the infobox would look like. I went with just a new line of text instead of adding a still frame for the sake of simplicity and to avoid increasing the size of the infobox too much, but using those frames is still a possibility if people want them. Something I can't figure out is what to say to the left of the "Animation" parameter; for now I went with "Available", but it's very likely there's something better that could be placed there. Any ideas?
2. The server does not allow files that big to be uploaded. We could either use external links (which of course aren't as reliable as the wiki, but would have the advantage of of not wasting this site's bandwidth) or ask Emily for a special upload permission specifically for this project. What do you people think?

Erasculio 00:52, 26 October 2008 (UTC)

I like Available/Not Available, at least for the time being. As for uploads/links, I would prefer to keep everything in-house, for the sake of simplicity and easy management if at all possible. I'm sure Emily and IT could find time to do their thing somewhere along the line. Should we set up a project soon, or should we hold off for more discussion first? calor (talk) 02:23, 26 October 2008 (UTC)

IMO, if by the time Emily solves the upload problem no one has objected, I think we could start a project. All wiki conditions would have been fulfilled. Erasculio 12:08, 26 October 2008 (UTC)

Aye. All we would need is a handful of dedicated people. I've never done animations/in-game video capture, but I'm sure I could figure it ou with a bit of testing and reading. calor (talk) 16:04, 26 October 2008 (UTC)

Somebody finally make a project page ~ Kurd 17:07, 26 October 2008 (UTC)

I'll get on this with Monk animations. But I'll be using Camstudio, I think. --Antioch 17:27, 26 October 2008 (UTC)

Wait, something important: What are we going to do with something like Reversal of Fortune? It can be cast on an ally, but to show the activation animation (ally being hit) we'd have to have a player hit the "allied" target dummy. How will that work? --Antioch 17:31, 26 October 2008 (UTC)

Enjoy. I like the look and feel of Camstudio over Fraps (so thanks for the name, PoA). If I find time, I'll try to work on Ranger skill in Isle of Wurms and Isle of the Nameless. We'd need two people for things like that. Or maybe a hero. I got teh dumb today. calor (talk) 17:34, 26 October 2008 (UTC)

For skills targeting allies, I'm using a hero in the Isle of Wurms, like here. Erasculio 17:59, 26 October 2008 (UTC)

Yes, but what of activation? Such as Protective Spirit, you'll see a blurry barrier when an ally is struck. --Antioch 18:18, 26 October 2008 (UTC)

Thinking clearly now: Go outside of Kamadan or something and get hit by a termite or Iboga. calor (talk) 18:25, 26 October 2008 (UTC)

(Reset indent) I'll start with the Imbagon ~ Kurd 18:27, 26 October 2008 (UTC)

Well, I could, but we should standardize this. Where and by what should I get hit by? Also, should it be a different file (as in name as well) to the casting animation? Monk skills are complicated...--Antioch 18:29, 26 October 2008 (UTC)

Heh, all professions have some complications. Assassins have the shadow stepping skills, making the recording somewhat annoying. Warriors and Paragons have adrenaline to be concerned about; Necromancers need bodies for a few skills, Elementalists have skills with 15+ seconds long animations, Mesmers have some animations that only appear when the target is interrupted, and so on.

Since we have so many people eager to begin, I have made a sketch of a Project page here. I would be very happy if people could add a bit to it, even if only to make it prettier - I was trying to make some nice looking tables for each profession, showing how many skills of each attribute have been done, using the colors of each profession, but so far it's not working... Erasculio 18:36, 26 October 2008 (UTC)

Splitting Kurzick/Luxon Allegiance skill icons

This is a continuation from a discussion on the talk page for Aura of Holy Might. Thanks to User:Brains12 for pointing me here.

My suggestion is to split up the double-icon images used in the various Kurzick/Luxon skills and thus splitting up the reference pages per skill variant. I am willing to split the icons myself, but I will have to request some backup in getting the pages copied. In order to preserve the relevance of the standard skill names (e.g. Aura of Holy Might, Elemental Lord, Ether Nightmare, etc.), I propose the creation of a disambiguation page for each skill, pointing to the page for each version per faction. This will allow for the skill icons to be used in a reference format without breaking page formatting.

If I need to clarify anything, please let me know. Once I have sufficient support, I'll begin work on this. --Kheraz Zarahi 12:22, 20 October 2008 (UTC)

There are some skills that are real duplicates, like Teinai Crystals and Crystal Wave, but Luxon/Kurzick icons are not. They are completely the same, just changing skill icon and Kurzick/Luxon. The anme is the same, and the description you get to when clicking the name of the skill in the help tab is the same. MithTalk 13:32, 20 October 2008 (UTC)

They are different skills. You are simply not allowed to equip both. Ɲoɕʈɋɽɕɧ 00:20, 21 October 2008 (UTC)

Both skills having the same name and being from the same campaign really reduces the significance of the separation. I'd consider a disambig page to be more cumbersome than double icons. 66.190.15.232 05:21, 21 October 2008 (UTC)

(Reset indent) If you are talking about the actual icons (images) then I can tell you that all the Luxon/Kurzick skills do have separate icons. Simply add (Luxon) or (Kurzick) before the .jpg in the image name. Example Image:Ether Nightmare (Luxon).jpg or Image:Ether Nightmare (Kurzick).jpg You can also find them all at Category:Luxon skill icons and Category:Kurzick skill icons I don't see why disambig pages are necessary, as the combined image works fine on the skill pages, and if you wish to use the separated icons in skill bars they are already available.

-- Wyn 06:44, 21 October 2008 (UTC)

How does this affect the game link redirect system? Do both "versions" of the skill in-game have one game link? --195.195.129.3 07:36, 21 October 2008 (UTC)

The in game links all redirect to the single page for the skill, where the description, and usage are described. These are NOT separate skills, they simply carry a different icon in game based on which faction you learned them from. You can learn both "versions" and the mechanics of the skill will be based on your title rank for whichever side you have equipped.-- Wyn 07:45, 21 October 2008 (UTC)

I was completely unaware of the skill images already being split. Taking that into consideration, I see no further reason to continue to support my initial idea. --Kheraz Zarahi 09:32, 21 October 2008 (UTC)

Wiki linking all "elite" tags in Related Skills

Why are all the "(elite)" tags wiki-linked in the related skills section of several skill pages. See Life Attunement or Shadow Form. Since I see no guidelines about tags in this article, I'll refer to the general one, namely this one: [1]. --8765 03:14, 9 June 2009 (UTC)

Because the person adding the skills weren't aware of the guidelines, probably. Feel free to change such things. - anja 08:13, 9 June 2009 (UTC)

Standardized Minion Navigation Bar

I've already posted this on skill pages that animates/creates minions (example: see Aura of the Lich) and it serves as an easier to navigate List of minion skills; I also think that Additional skills section should also be tagged with this since all are 100% relaint on the presence of a minion to work effectively. Thoughts? --Falconeye 06:35, 11 July 2009 (UTC)

I think it's handy but at the same time it's for minion skills too but most of he minion creating skills already have other minion skills too. -- Halogod35 06:39, 11 July 2009 (UTC)

I think the "related skills" section of most of the minion skills is way bloated. So, I'd be happier with a Minion Creation nav instead of a list of all the minion creating skills. --JonTheMon 13:59, 11 July 2009 (UTC)