Guild Wars Wiki talk:Formatting/Skills/Archive3

Non-elite Acquisition Order

I think that the order for acquisition of non-elite skills should be:

1. Skill quests:
2. Profession changers:
3. Skill trainers:
4. Signet of Capture:
5. Hero skill trainers:

Instead of the current order in the example:

1. Skill quests:
2. Hero skill trainers:
3. Profession changers:
4. Skill trainers:
5. Signet of Capture:

It makes sense to have hero skill trainers last because all of the other acquisition methods are for obtaining the skill on your character and not just unlocking it.

When you unlock stuff at hero skill trainers, you also gain that skill yourself if it is for your profession, so I don't agree with you. :) Atm it's sorted by cost, cheapest first. If you unlock a skill for you own profession at a hero skill trainer, it is indeed cheaper than a normal skill trainer. - anja (contribs) 18:22, 12 June 2007 (UTC)

See I don't know if that was an intended effect or if it's a bug. :P - BeX 03:36, 13 June 2007 (UTC)

Its not a bug, its a feature! ;-) Anyway, as long as it works, I agree with keeping Hero skill trainers on top since they are cheapest. --Xeeron 07:58, 13 June 2007 (UTC)

If I recall correctly, I accidentally tested this, and you get the skill even if it is not one of your current professions. -- Dashface 00:30, 14 June 2007 (UTC)

Progression revisited

We'll need to adjust template:skill infobox to account for the progression of Allegiance rank and Sunspear rank skills. I suspect that the green numbers for Sunspear skills represent either 0 and 10 or 1 and 10, and that the green numbers for Alleigance skills represent either 0 and 12 or 2 and 12, however it's also possible that they use the same 0...12 progression as other skills. -- Gordon Ecker 02:18, 16 June 2007 (UTC)

It looks as tho the green numbers are 1 and 8. For anyone else not watching it, please look at Talk:Sunspear rank. - BeX 05:59, 16 June 2007 (UTC)

Sunspear Rank Skills Acquisition

Are we listing only the first hero skill trainer that these new skills become available at? I don't think it's limited to the guy at Sunspear Great Hall, like I have been seeing under the Acquisition section of the skill articles. Is a link to Hero Skill Trainers good enough? - Thulsey - talk 09:15, 16 June 2007 (UTC)

Only adding Shiloh under acquisition was an oversight on my part - I assumed that they'd only be available in the Sunspear Hall, for some reason (perhaps due to the fact I was editing at 5am :/ ). I agree that just a link to Hero Skill Trainer makes a lot more sense. AT(talk | contribs) 09:21, 16 June 2007 (UTC)

Please, link to Hero skill trainer ;) - anja (contribs) 09:28, 16 June 2007 (UTC)

Unlocking via heroes

Should we include any mention of skills which are unlocked when you recruit a given hero, or skills from the default PvP builds which are always unlocked? I believe it is revelant because unlocked skills are available from all trainers in the appropriate campaign(s), and there's a huge difference between "no known trainer" and "no known trainer because it's always unlocked" or "no known trainer because it's unlocked near the start of the campaign when you recruit <hero name>". -- Gordon Ecker 04:18, 26 June 2007 (UTC)

I guess this can be an good addition. --  (CoRrRan / talk) 11:48, 28 June 2007 (UTC)

I agree that it would be a good addition. Reminds me of Envenom Enchantments or even Sprint...--Bane of Worlds (talk • contribs) 12:58, 28 June 2007 (UTC)

Unlinked or No Attribute?

If anyone has the time, I'd appreciate comment/opinions here AT(talk | contribs) 12:22, 28 June 2007 (UTC)

I'll post it here, since I think it's relevant to all skills. Attribute is an optional parameter. If there's no attribute for a skill then you should omit the attribute line. LordBiro 12:34, 28 June 2007 (UTC)

For categorization, I'd prefer "No Attribute", as that's the tab name in the Skills and Attributes panel. -- Gordon Ecker 00:09, 29 June 2007 (UTC)

Environmental effects

Shouldn't we set any kind of defaults for those? Yup, they are not 'skills' but that can be started as skills, and sometimes the game itself gives them types like 'skill' or 'signet'. They just seem to be 'out' of anywhere, and you just see pages without any default appearance, just the icon and a breaf description, and many of them have durantions, effects, ingame descrptions, etc... MithranArkanere 15:42, 2 July 2007 (UTC)

And according to the Game link namespace, they are considered skills by the game.. Since they have "Skill" as identifier together with normal skills. I think we should use the skill infobox for those too. - anja 15:44, 2 July 2007 (UTC)

Yeah, but what I mean is that they could have an own background for the info box and no entry for 'attribute' instead of the 'No attribute' entry. There could be a 'Environment = y/n', like the 'elite='. Just to make them different. MithranArkanere 15:49, 2 July 2007 (UTC)

Uh-oh... does that mean we need to tag those environment effect icons as well? :D -- ab.er.rant 01:47, 3 July 2007 (UTC)

Oh bleh. :P - anja 07:45, 3 July 2007 (UTC)

Why not "special = Environmental"? This would categorise the article into only Category:Environmental skills. LordBiro 08:58, 3 July 2007 (UTC)

Would that remove the attribute line also? - anja 09:01, 3 July 2007 (UTC)

Yes, special overrides everything. It's meant to imply that the skill is not a regular skill, so monster skills are special, as are junundu skills etc. LordBiro 09:06, 3 July 2007 (UTC)

Sounds like a good solution to me. Category:Environmental skills or Category:Environmental effects? - anja 09:07, 3 July 2007 (UTC)

Actually I might not have answered your previous question correctly. Special removes the attribute category, but the line "Attribute: No attribute" still appears in the skill box. I don't know if this would pose a problem.

By default the skill box takes the parameter {{{special}}} and puts the article into [[Category:{{{special}}} skill]]. If Environmental effects is the right term to use then I'm sure we could code an exception into the skill box to accomodate it! :) LordBiro 09:20, 3 July 2007 (UTC)

Then it's maybe easier to use some kind of environmental=yes? Because we would want the attribute line to disappear, the category to be special and the infobox to say it's an environmental effect somehow. Seems like an awful lot of special coding to get it to work with the special parameter.. - anja 09:29, 3 July 2007 (UTC)

You're right, although I suspect most (if not all) special skills shouldn't have an attribute line, so this particular issue wouldn't be coded for Environmental effects but for special skills in general.

It might be easier to use environmental=yes... My main motivation behind using special is that special is for situations where a skill wouldn't appear in your skill list, and this is certainly one of those situations. I reckon that the amount of code needed to implement the "environment" variable is probably the same as it is to code an exception into the special variable to categorise into Category:Environmental effects. LordBiro 10:04, 3 July 2007 (UTC)

(Reset indent) Hm, maybe we should code into the infobox that all skills that are special (Special parameter) should hide the attribute line then. And if we do that, it would be kind of the same amount of code to implement environmental parameter as to specify the special parameter. Special=environmental makes more sense also, since we use that for monster and junundu skills. - anja 10:09, 3 July 2007 (UTC)

I've altered the skill infobox to omit the attribute line if special is set, as you can see it's a very minor change! :) LordBiro 12:54, 3 July 2007 (UTC)

Great. :) But something has screwed with the infobox, not your last edit though it seems. Things aren't showing up in new lines as it should. It shows like: Campaign Core Profession <newline> Monk, if you get what I mean. - anja 12:57, 3 July 2007 (UTC)

That was actually because I was messing about with the item-infobox.css file, I forgot other people might be using it, sorry! If you control+refresh you should see the problem is fixed. LordBiro 13:00, 3 July 2007 (UTC)

Well... there are not just Monster(like Spectral Agony), Mission(like Holy Water) and Event (like Rollebeetle) skills, there are also Skills without the 'skill', like Blessings, Disguises and Environment effects. That's Why I think we should remove the 'skill' that the template adds by default to the 'special' attribute. Yep, it would be annoying to update all the currently existing pages. But hat way it would be completely standardized. The sooner it's done, the better. I hate a bit how blessings and disguises are set for now, completely out of Formatting. MithranArkanere 17:32, 3 July 2007 (UTC)

I tend to agree. I'm sure a bot could update many of the articles. What do you think of this Anja? LordBiro 17:36, 3 July 2007 (UTC)

If a bot can do the tedious work of updating, and it makes using the infobox more logical, I'm all for it.
(edit) Could we also agree on the name? Bounty or blessing, environment effect or environmental effect, etc, let's agree on that before creating alot of articles. - anja 17:43, 3 July 2007 (UTC)

Effects are called environmet effects in the English version descriptions. So I think that's the one we should use. For the case of Bounties and Blessings, When a blessing is also a bounty, it could be used Type: Blessing, Special: Bounty. See? Everything like a clockwork. Sylar would be proud of us. MithranArkanere 17:47, 3 July 2007 (UTC)

Ok, Environment effect. What do we put in type when special is Environment effect? No need to list things twice.. - anja 17:49, 3 July 2007 (UTC)

I've seen a lot of Enviroment effects, and not all of them are the same type. I've seen 'Enchantment' (Not Enchantment spell, just enchantment), 'Signet', 'Blessing' and most of the time 'Environment effect'. It's like skills, sometimes they have own tipes, and sometimes they are just 'skills'... they are just effects that you receive when walking within an area, the type may be always different. MithranArkanere 17:52, 3 July 2007 (UTC)

I just checked Edge of Reason, and that one doesn't even say Environment effect. :/ This is going to be tricky.. - anja 18:23, 3 July 2007 (UTC)

What about using special = Environment Effect and type = <whatever type the description uses>, with type defaulting to something like "not specified"? -- Gordon Ecker 02:18, 4 July 2007 (UTC)

Good idea. - anja 08:20, 4 July 2007 (UTC)

Allegiance rank skills, Kurzick & Luxon Icons

As there are 10 Allegiance rank skill each with one Kurzick and one Luxon icon a discussion at Talk:Allegiance rank started on which icon we should use for documentation.
I would suggest to use a double sized icon (128x64px instead 64x64px) for the infobox which has the Kurzick icon on the left side and the Luxon icon on the right side (because of their positions in Cantha). By this way we could use both icons for the skill infobox without modifying the template. Additional to this double-icon we can upload each version to make both icon versions (Kurzick and Luxon) available.
For example Selfless Spirit: Image:Selfless Spirit.jpg (double sized image), Image:Selfless Spirit (Kurzick).jpg, Image:Selfless Spirit (Luxon).jpg poke | talk 19:30, 7 July 2007 (UTC)

As said over at Allegiance rank, I like this idea. - anja 19:35, 7 July 2007 (UTC)

I agree with using both images, but that idea isn't going to work, at least not without some work :) LordBiro 19:42, 7 July 2007 (UTC)

What about 64x128px? ^^ poke | talk 19:44, 7 July 2007 (UTC)

Yeah, that would work :P I updated the test page! LordBiro 19:49, 7 July 2007 (UTC)

(edit conflict) I was too late ^^ But it works :) poke | talk 19:51, 7 July 2007 (UTC)

Neat :) - anja 19:56, 7 July 2007 (UTC)

Sugar Jolt has also two icons.MithranArkanere 04:09, 8 July 2007 (UTC)

DPL and skill lists

Since DPL is working now, time to start the list designing? Quick refs of all sorts and kinds would be lovely, and DPL seems to make it quite easy. Brought this up here, since we probably want to have some kind of standardized look on them. - anja 17:21, 12 July 2007 (UTC)

CoRrRan has been playing with the DPL a bit - I think it's worth mentioning that here since apparently there is a question about how to add the skill descriptions to the lists, given how they have no heading (myself, I have no idea of how the coding works : P). I apologize if he wouldn't like that link to be here. Erasculio 17:27, 12 July 2007 (UTC)

Probably it is possible to get it out of the article, but I think one solution is also to have it inside the template and call it from there. I'm not really great with this DPL thing, I just know I want lists. :) - anja 17:30, 12 July 2007 (UTC)

Further on the DPL thingy. As you can see, my example is becoming better and better, but I want your input on how the skill quick reference lists are to be formatted. I'm trying to mimic GuildWiki at the moment, as a test case, but perhaps someone has better ideas. Or should I just continue until I get this working properly and then worry about formatting and content? DPL is still a big unknown to me, but I seem to get rather nice results at the moment. --  (CoRrRan / talk) 20:31, 15 July 2007 (UTC)

CoRrRan, you're very brave to deal with DPL without knowing it in details - I know I just muttered something when I saw it and decided to wait until someone with more knowledge or more courage were willing to go through that code. Thanks for working on it : )

So far, I like the GuildWiki style, using the colours of the profession around the name of the skill. I was wondering if it would be possible to add an icon to let we know what skills are available from quests (like in the GuildWiki lists, with the green exclamation point) and what skills are available from Hero Skill Trainers (again like the green exclamation, but using a different icon). Erasculio 20:47, 15 July 2007 (UTC)

It looks great CoRrRan. It's definitely time to start discussion on their formatting, but I think it would benefit us alot if we know about DPL's formatting limitations. So, I'd say go ahead and try stuff, that way we have one more who knows DPL :P - anja 20:51, 15 July 2007 (UTC)

Hehe, well, I've now encountered a problem where I don't see a quick solution. I want to extract a variable from the {{skill infobox}} (elite = y) and use a ParserFunction "if" to change the bgcolor=attribute of the 2nd column. But I don't know how to get that variable...

On this depends quite a lot of the features that Erasculio would want to have... and by the way Erasculio: if you want those things, the {{skill infobox}} will have to be modified immensely to incorporate variables like "canbetrainedfromheroskilltrainer = y" as well as "quest = y", AFAIK. Although perhaps we can retrieve the Category:Mesmer skill rewards from the pages and use that as a variable in a ParseFunction if-statement.

I just wished I was more adapt at working with those functions... --  (CoRrRan / talk) 20:58, 15 July 2007 (UTC)

If's are my friends, let's combine our wisdom? ;) I'll move over to your example and try to understand something.. - anja 21:01, 15 July 2007 (UTC)

Sure, see User_talk:CoRrRan/DPLSandbox for an explanation of my problem. --  (CoRrRan / talk) 21:12, 15 July 2007 (UTC)

Description labeling

The current format with the skill description does not allow DPL to extract it specifically. There are at least a few ways to allow it:

1. Add a header ("Description"? "In-game description"?) over it. Also, separate the progression table into its own header. Then DPL can grab it by referencing %1 (the first section with a header) or "#Description". There seem to be many who don't like the visual look of such a header.
2. Add a "description" parameter to the infobox that just outputs the description at the end, and within each skill page, move the description text into the infobox template call. Then DPL can work with it inside Template:Skill infobox dpl. The rendered output looks the same; the description is just moved into the infobox code-wise but not visually.
3. Add a header above the progression table (just to separate it from description) and move the infobox below this first header. Then DPL can grab the description by referencing %0 (the section above the first header). I'm not sure if there is a way to prevent the rendered infobox from lowering with this.
4. Add "labeled section tags" around the description, e.g.:

<section begin=description/>[[Signet]]. Cleanse yourself of [[Poison]], [[Disease]], and [[Blind]]ness.<section end=description/>

DPL can then grab it by referencing "description". This method does not change the look of the skill pages at all, but adds some unfamiliar markup to the wikicode. --Rezyk 18:53, 12 July 2007 (UTC)

Among those options, I like 2 and 4 the most - I really like how the current skill pages look, they have a very "clean" feeling to me. I think 4 would be easier to "mass produce" as it would be a matter of using control-V at the beginning of each page and then control-V at the end of each description, as opposed to moving content from each page around (such as would happen with 2, assuming I have understood it). Erasculio 18:58, 12 July 2007 (UTC)

(edit conflict) I would personally prefer solution #2 or #4. The general article formatting guide says "no starting header" as the article name itself is a header. And I also prefer having the infobox at the top. - anja 18:59, 12 July 2007 (UTC)

I'm with 2 or 4 too. 2 Better than 4. MithranArkanere 19:35, 12 July 2007 (UTC)

I would prefer option 4. It could be easily done by a bot.. poke | talk 22:36, 12 July 2007 (UTC)

Option 4 but 2 would be alright also.--Bane of Worlds (talk • contribs) 22:39, 12 July 2007 (UTC)

I'm going with 2. 1 and 3 would cause inconsistency with other pages. 4 introduces an unnecessary tag. Adding a parameter to the infobox keeps things more consistent. -- ab.er.rant 04:35, 13 July 2007 (UTC)

But adding a new parameter would mean to type the description two times... Or can we use dpl to extract the description on skill pages out of the infobox? poke | talk 08:51, 13 July 2007 (UTC)

I think that would be possible, therefor, I think #2 is my preferred option too. --  (CoRrRan / talk) 10:38, 13 July 2007 (UTC)

I've put up an example with the description typed once at User:Rezyk/Sandbox. --Rezyk 10:47, 14 July 2007 (UTC)

After some more thought, I realize now that #4 may not be able to give us the results we probably want. Specifically, it does allow the description to be extracted and put in a DPL table...but I think the description would have to go at the beginning or end of each table row and not the middle of it. So, #2? --Rezyk 10:47, 14 July 2007 (UTC)

Since parameters can be used as many times as we want, anywere we want, once the data is intruduced, #2 is better. You could make it appear after the name. We'll need to 'move' all the currently existing descriptions to that parameter:

last parameter=value}Description -> last parameter=value new_parameter=Description}MithranArkanere 11:49, 14 July 2007 (UTC)

If it's that easy with #2, just mocing the description inside the template in a description parameter, I'm all for it. It's not making the article harder to edit in any way. - anja 12:35, 14 July 2007 (UTC)

It's really the easiest thing to put the description into the template. I added a bot request for doing that. When it's decided they can start. poke | talk 18:02, 14 July 2007 (UTC)

Let's get this bot rolling... skills don't update themselves. I think the way Rezyk has modified the skill infobox template, and his example here shows how nice this looks. --  (CoRrRan / talk) 02:29, 15 July 2007 (UTC)

I agree, it does look rather nice. There's something I haven't understood, though (warning, wiki noob here) - if the bot Poke asked for is created, does that mean we would not have to edit any skill at all ourselves? If we do, I would like to know in order to start (it's going to take a while to edit all those skills). Erasculio 03:45, 15 July 2007 (UTC)

Since it is only a simple RegEx-search and replace, I think the bot will be able to modify ALL skill pages itself when it runs. No need for any user input/modification. We'll just have to harass Pepe to start his bot, since Dirigible's isn't available. --  (CoRrRan / talk) 03:54, 15 July 2007 (UTC)

Can someone help me to get this suggestion to an approved consensus? I want to add the description into my DPL example, but I can't due to it not being in the template. --  (CoRrRan / talk) 19:49, 15 July 2007 (UTC)

Do a test edit with one or two skills? (easy to revert if consensus fails, which I don't think it will) Or try out rezyks example in his sandbox? - anja 19:53, 15 July 2007 (UTC)

Hmm, I can change 2 or 3 skills for my example and start from there, I agree. But perhaps I'll break the search and replace of the bot if there are already skills changed. Just hoping that somehow I can figure out when "a consensus is reached". Is there a definition on that? Do we need 2 or 3 people to confirm? Do we need 100+? Do we just need LordBiro to say "Make it so!"? I just don't know. It's not like this is ground breaking policy stuff like on the GWW:USER-page. :) --  (CoRrRan / talk) 20:00, 15 July 2007 (UTC)

It's not that formalized. If this was a policy change, there's Guild Wars Wiki:Policy#Changing existing policies, but it's not. Personally, I feel that there is enough of a consensus support shown here already to just go ahead, but it's really your call as much as mine. --Rezyk 20:10, 15 July 2007 (UTC)

As I haven't seen any negative comments so far, we can go ahead now, imo. *poke Pepe to go botting* :P - anja 20:11, 15 July 2007 (UTC)

I agree, I think there is already some sort of consensus about this. Erasculio 20:21, 15 July 2007 (UTC)

I went ahead and modified the formatting guideline. --Rezyk 20:36, 15 July 2007 (UTC)

I've finally got a regex that's working, I'm starting the run now. MisterPepe talk 02:35, 17 July 2007 (UTC)

I've put up a list of all the skills that still need their descriptions moved into the skill infobox at User:Cloud/Unfixed_Skills, these were not processed by the bot and in general are specialty skills, environment effects, etc, but there are only ~120 of 'em so feel free to fix away :) Cloud 23:57, 17 July 2007 (UTC)

Updated list, now down to 82 Cloud 16:03, 23 July 2007 (UTC)

New skillbox tag for availability

I mentioned this above, but I don't want to derail the discussion on DPL, so here it is. Now that skill lists are possible, I was wondering if it would be a good idea to add one thing that GuildWiki has - an icon at the skill lists letting the player know if a skill is available as a quest reward or not, so he would not waste gold buying it. We could expand that idea to work with skills available from Hero Skill Trainers, given how those are also free.

In order to do that, we would need to create a new tag on the skillboxes, so DPL was a source from which to extract this information. My proposal is to add a new tag similar to the "elite" tag - something to be added only to the skills that are available this way (so only a minority of the skills would need an edit) and that would not be visible on the skill page itself (given how the Availability section on each page already has this information). Erasculio 03:24, 16 July 2007 (UTC)

I can think of the following variables:

• Questability
  • Prophecies (pre-searing)
  • Prophecies (post-searing, native only)
  • Prophecies (post-searing, native and foreign characters)
  • Factions (native only)
  • Nightfall (native only)
  • Eye of the North
• Hero skill trainer availability
  • Nightfall
  • Eye of the North
• Profession changer availability
  • Crystal Desert
  • Battle Isles

It might be possible to handle everything with a smaller number of parameters depending on how DPL works. -- Gordon Ecker 06:09, 16 July 2007 (UTC)

My vote goes to fewer paramaters: like maybe one. All that is required for this purpose is a little visual trigger that says 'hold on! don't click Purchase too fast there, fella/fell-ette!' and a link to the skill page. The skill itself has all acquisition information, I don't think it needs to be in a quick list.

Perhaps a single parameter in the infobox as free, which is by default set to 'n'? - Thulsey - talk 06:27, 16 July 2007 (UTC)

If we want to be exhaustive, we could represent questability with the letters P, F, N and E in the questability box, with bold indicating availability to foreign characters and italic indicating availability only in pre-searing. The profession changer box could use C and P, and the hero skill trainer box could use N and E. Or we could show all free availability in one box with text style used to differentiate native availability from non-native availability. I'd also be okay with a single box and a single yes / no flag denoting free availability. An extreme option would be incorporating the entire acquisition section into the infobox, but I don't think it would be worth the added complexity. -- Gordon Ecker 06:39, 16 July 2007 (UTC)

(Edition Confliction :P ) I fear redundancy in a more exhaustive system: aren't the pre-searing only skills all the same skills that unlock when you change secondary in the desert, for instance? Are there really many questable skills that don't unlock in Factions and Nightfall when you switch your secondary in that campaign, even as a foreign character (I really don't know so it's not a rhetorical question ^^ ). I see a need for the information but I favor the simple tag that says 'this item may be available to you for free: you should check it out.

Anyway, let's talk it out and get others in the discussion. I'm easily persuaded, most of the time. - Thulsey - talk 06:51, 16 July 2007 (UTC)

There's a few questable pre-searing skills and questable nightfall skills that aren't available from the profession changer. About half of the questable skills in Factions (mostly the ones from Instructor Ng's quests) aren't available from the profession changers. We could go with five parameters for core, prophecies, factions, nightfall and eye of the north, each of which accepts three values: none, native-only (possible represented by N) and universal (possibly represented by A or U). Anyway, I agree that a single true/false parameter indicating that you may be able to get the skill for free would be sufficient. -- Gordon Ecker 07:11, 16 July 2007 (UTC)

I think the nicest solution is the one someone already mentioned, just a little something that tells the reader "This skill is available cheaper than normal" and the reader can just click on the skill name to find out how. That would be a simple solution that doesn't require a multitude of parameters. - anja 09:38, 16 July 2007 (UTC)

I agree with the simpler solution. I think saying "questable = y" makes sense. LordBiro 10:16, 16 July 2007 (UTC)

I would rather have the simpler solution as well. While the idea of using letters would make the information more detailed, I think it risks not being clear enough to someone who did not know the letter code before looking at the list. An iconic symbol, as long as it's something easily recognisable, would make the information that "wait, this is free!" easier to be grasped in the context of a quick reference list. Erasculio 10:52, 16 July 2007 (UTC)

Although questable is misleading, since we have hero skill trainers and profesion changers also. But I can't think of a better parameter name.. "free = y" ? :P And I'm sure someone can come up with a wonderful icon that screams "Wait, check this out!" :P - anja 11:11, 16 July 2007 (UTC)

"Questable"? Um... errr... don't like it :P Why not just "quest = y"? -- ab.er.rant 11:30, 16 July 2007 (UTC)

! - BeX 11:32, 16 July 2007 (UTC)

Did you even read what I wrote Aberrant? quest isn't everything, we need something that includes the other options :P And awesome icon Bex, could you make it visible in a smaller version too? ;) - anja 11:34, 16 July 2007 (UTC)

Yea, I know. I was about to reply to remind myself to smack myself in the head for not reading the whole thing first, but Bex hit me with and edit conflict. :P -- ab.er.rant 11:35, 16 July 2007 (UTC)

Questable wasn't really a genuine suggestion, but I thought as soon as I posted it that it could be construed that way :P I just mean, the parameter should just show whether or not you can get this skill from a quest. I think if there are other ways you can get it for free then they should have their own parameter. heroskill = y etc. LordBiro 11:42, 16 July 2007 (UTC)

It looks like a sunny side up egg. I made it in msn. Scourge said it was terrible so I had to show. :P - BeX 11:49, 16 July 2007 (UTC)

(Reset indent) The reason I wan't just one parameter is because I'd like it to be only one icon showing in the list, and have the reader find out himself what kind of different method it is. I think it would be more simple to implement, and would clog the skill lists with alot of odd icons. How do you make a good "A hero skill trainer can teach you this"-icon? :P
Would an exclamation mark icon work, if we use the same icon for all methods? It may indicate it's just about quests, but it could be explained at the top of the skill list anyway. - anja 11:46, 16 July 2007 (UTC)

I realize Anja Astor was joking when she proposed it, but if we are going to use a single parameter, so far my favourite suggestion has been "free = y". That does include everything, from skills available through quests to skills taught by Hero Skill Trainers to skills available when changing professions. Erasculio 18:28, 16 July 2007 (UTC)

Adding a category would not be bad, either. Many players like to know wich skills are free to purchase only those that are not. MithranArkanere 19:19, 16 July 2007 (UTC)

If we are going down the route of using a single parameter for all alternative acquisition methods then I don't think that we should use the term "free = y" since this isn't really accurate. LordBiro 21:29, 16 July 2007 (UTC)

We can always use "raptors = yes". *tongue in cheek* Man, I'm in a silly mood today...

Together with Cloud, we also want to introduce a lot more tags to the skill infobox. Any idea how we are to do that? It's definitely not crystallized yet, but if the skill infoboxes have been set up, it would be a breeze to use DPL to create lists like this: List of skills by related subject. --  (CoRrRan / talk) 21:39, 16 July 2007 (UTC)

I was inspired by the egg! - Thulsey - talk 02:20, 17 July 2007 (UTC)

How about "alt acquisition = y" then? or "alt acquire = y" or even "alt get = y" -- ab.er.rant 02:33, 17 July 2007 (UTC)

Maybe that's coming at it from the wrong way? If it's just a single tag, how about "Skill Trainer Only=n"? - Thulsey - talk 02:52, 17 July 2007 (UTC)

I like both the idea of "Skill Trainer Only = n" and the icon above - although I'm not that fond of eggs, I think it's shiny enough to capture the attention of users and make them realize that there's something different about those skills. What I'm really dying to know, though, is what does that "i" stand for : P Erasculio 03:01, 17 July 2007 (UTC)

Information? :S - BeX 03:04, 17 July 2007 (UTC)

OOoooh, shiny! - BeX 02:55, 17 July 2007 (UTC)

i=Imperio Curse (sorry, just saw Harry Potter :P ) Actually, BeX is right, i=information; for whatever reason, a user should stop and check it out in more detail. There's a version on my computer with a hand in the 'talk to the hand' formation. Was going to make it red, but... I think I have mentioned my feelings on big red stuff somewhere else in the past. >_>

This was a first draft only; would like to make it more like the icons in the skill infobox. - Thulsey - talk 03:14, 17 July 2007 (UTC)

Have you ever used inkscape, Thulsey? I could send you the files I used to produce the icons in the skill infobox. :) LordBiro 10:27, 17 July 2007 (UTC)

No, never used inkscape, though I've seen documentation and videos on it. I have used Illustrator, Freehand and Fireworks quite a bit, so I know my way around vector graphics, but inkscape didn't look quite as intuitive. I've been meaning to download it for a time now, so if you wouldn't mind sending me those files I'd love to use this as a chance to play around with them and see what I can come up with. You've set that bar pretty high, though. ^^ - Thulsey - talk 15:08, 17 July 2007 (UTC)

I, would = "Imperius" Not Imperio..

Infuse Health and other skills with lots of 3 digit numbers.

Talk:Infuse_Health#Cleanup It needs sorting, and until it is the tag needs to stay. --ChronicinabilitY 16:15, 28 July 2007 (UTC)

I'm thinking of a method to rewrite the progression template to autowrap when not enough space.. Will try something.. back in some minutes ^^ poke | talk 16:33, 28 July 2007 (UTC)

Was just about to ask you, thanks Poke ^^ - anja 16:35, 28 July 2007 (UTC)

Ok, here we are: User:Poke/sandbox - it works, but first: I want to have the headings on the left to be there and prevent the values from wrapping below them -> needs improvement; second: The code is really huge! Will look if I can save something.. maybe we have to add a new style to common.css. poke | talk 17:22, 28 July 2007 (UTC)

(EC) I'm personally opposed to keeping the tag there, especially when there is now a discussion on this page, where in my opinion the issue should have begun in the first place. But let's get this fixed. I also find the revert war (because that's what is is now) ridiculous. A very good case for placement of a {{disputed}}-tag. (See Guild Wars Wiki:One-revert rule (note: this is a proposed policy).)--  (CoRrRan / talk) 17:25, 28 July 2007 (UTC)

Now I like it :) I will try to make a template from this now. Any comments? ^^ poke | talk 18:53, 28 July 2007 (UTC)

Well, it's a solution, but I find it a bit "funny" that suddenly the indicative description has all those values right next to it. Although I understand that getting the 1st column to repeat itself for every 2 rows is just impossible. So this IMO is a workable solution. Are you going to modify the skill-progression template or are you going to make a new template? --  (CoRrRan / talk) 18:57, 28 July 2007 (UTC)

As this solution is just for users which cannot display the box in its full width, there is no need to make it perfect (which is here impossible without using Javascript). So I think it is ok when the box displays without destroying the page layout (and I think it can be understood that the values belong to the headings on top-left). What I'm doing now is to find a solution to display the borders better; then I will try to make a template (first on my userspace, if it works I will update the existing template). poke | talk 19:22, 28 July 2007 (UTC)

Looks great Poke, as you say it's not meant to be viewed like that for every user, but to be a solution for special cases. - anja 19:34, 28 July 2007 (UTC)

Ok, finally I'm satisfied ^^ Now you have to decide: Having loads of style attributes or have a clear template by adding some styles into the common.css? poke | talk 21:47, 28 July 2007 (UTC)

If the CSS doesn't make something else go weird, I'm all for it. It's for the benefit of all users. (Ok, now I contradicted my statement above, but whatev.. :P) - anja 21:49, 28 July 2007 (UTC)

The css requires a table with the id "skill-progression" - as long as nobody uses this id for his tables nothing is going to be weird ^^ You can see the css code in my sandbox. poke | talk 22:00, 28 July 2007 (UTC)

Since a skill progression could potentially be used multiple times in an article (probably not a skill article but perhaps a guide) "class" should be used instead of "id". LordBiro 22:52, 28 July 2007 (UTC)

Yeah, that's true. I will change it. poke | talk 22:54, 28 July 2007 (UTC)

Monster skill icon

We never know if the will ever add new icons to replace the generic monster icon. We should avoid having them all getting the same icon. Or we could end up having a lot of skill list having incorrect icons for a long time if that happens. MithranArkanere 01:10, 2 August 2007 (UTC)

Are the monster skills sharing monster icons? As I recall, I've been mostly uploading the same generic icon for several monster skills. -- ab.er.rant 02:31, 2 August 2007 (UTC)

The {{monster skill}} template uses it. By using it, if they lately add icons for some skill (it won't be the first time) we'll have to manually seek and update all the files that have it. And, by the way, it's almost useless, we do not use it for all monster skills, only for those with the generic icon. As far as I can tell, that template it's just something with not much sense copied from GWWiki, even the skill info template is designed to use separate icons, as you can't manually set them. We don't have another template for elite skills to add the '(elite))'. A skill it's a skill, being it from a monster or not. I say, remove the monster skill template at all, and add to the formating to add the (monster skill) tag manually, like we currently do with elite skills, to make it generic and prevent any bothering problem if they ever add a new icon to any of those skills. MithranArkanere 11:07, 2 August 2007 (UTC)

We could also add an (elite skill) template, and change the (monster skill) template to ues the icon of the original skill. That way we could automatically categorize NPCs depending on the tipe of skills the use if we ever needed so. My main point is that is has not much sense to use monster skill only for some of them. MithranArkanere 11:25, 2 August 2007 (UTC)

(edit conflict) I think the monster skill template is great, it actually checks if there is a skill icon for the skill name put in, if there isn't, it uses the generic monster icon. So if an icon is added later, the template will notice and update accordingly.
Btw, the skill template does not support different image names, so all monster skills with the generic monster icons in the infobox has a unique version of it in it's infobox, see Nibble for example. That is a version of the monster skill icon and it's uploaded under the name Nibble.jpg. I don't think there will be any problem updating them, just replace the Nibble-jpg and it'll sort? - anja 11:41, 2 August 2007 (UTC)

As you've noticed, all skills need to have their own icon, as the template requires it. So the monster skill icon template is not used. Backsword 11:49, 2 August 2007 (UTC)

There are a lot monster skills which do not have an icon yet. So it's displays the generic icon. Also the monster skill icon template displays "(monster skill)" at the end. And this: An not yet existing monster skill! An not yet existing monster skill! looks not good, An not yet existing monster skill! (monster skill) is a lot better. :P poke | talk 11:58, 2 August 2007 (UTC)

Not that many now. I did some testing, and it seems to me that the monster version saw more use duing the early days of the wqiki, when most monster skills were not implemented, while the normal version is used more now. There's now dominant standard though, with plenty of NPCs using eith. Not that it matters, as I couldn't find anything that didn't work where they were used. The non monster version is slightly more flexible, as you might not want to have the extra note in tables and such. But I can't see that we need to do anything.

As for displaying an generic icon, I think that's caused a few errors, as people have goten the impresiion that a mistyped skill name was partialy implemented. I'm guessing that whats caused one I fixed. Might be few others lying about. Backsword 12:11, 2 August 2007 (UTC)

Ouch, so it uses the actual icon if there is one. Anyways, although it may look better, I think we should remove the generic icon, to prevent people thinking it's already uploaded, since getting a generic icon uploaded is as easy as going to Spectral Agony, downloaing its icon, and upload it again. And now. why don't we make the same with elite skills so the 'elite' gets automatically added? MithranArkanere 12:17, 2 August 2007 (UTC)

Using a generic monster skill icon is not for editors; it is for readers. Just because it is easier for editors if a red link is shown doesn't mean we should do it. Readers come first, writers come second :) LordBiro 18:50, 2 August 2007 (UTC)

Never made my position clear here, so I'll do it now. Better late...

Bascially, I think no icon is better than the wrong icon. Readers should be able to trust what we put in. Backsword 07:13, 27 November 2007 (UTC)

Historical Info?

Just tossing this out there to get opinions: do you think it'd be worth trying to document historical information about skills (i.e. pre-nerf/pre-buff aspects, et cetera)? I ask because oftentimes I'll be talking with a newer player or such, and referring to some old build (say, spirit spam, dual smite, whatever) and they'll tell me "well how can that work when such and such skill is limited in such and such fashion", to which I can only respond "well, it didn't use to be that way..." - it'd be sort of nice to have a way to show newer players how the game has changed. (Aiiane - talk - contribs) 15:21, 4 August 2007 (UTC)

I concur that historical info would be nice to be incorporated to the pages but you can still accomplish such by referring to the history of the page (works better for guildwiki as it was around longer then GWW) and refer to previous game update pages. This implementation would facilitate obtaining history of such pages regardless of these cumbersome methods. /support--Bane of Worlds 16:09, 4 August 2007 (UTC)

As a Wiki, that information is there. You only have to click in 'History'. MithranArkanere 14:47, 27 November 2007 (UTC)

Actually, I don't mind seeing articles on the evolution of skills, highlighting events or issues which caused them to be nerfed. The history shows changes, but it doesn't show why if the editor didn't bother putting in the reason. It could be a typo fix for all the reader might know. To accomplish this, we could add a "History" section below the usage notes, or (less ideally) create a "<skill name>/Change history" or something. -- ab.er.rant 14:57, 27 November 2007 (UTC)

Yeah. The history would work if people used the change description to put "Skill Change". But I don't really see the usage of such thing. Maybe just something in the notes for functionality changes in the Notes section ("Othyugh cry used to affect neutral animals", "You had to use the signet of capture when the boss used the skill" etc...), but why to denote all +/- in the values? 10 energy instead of 5...? The historical data does not affect gameplay. And too many changes have happened since the first days of the game to be able to track all of them for all 1319 skills now. MithranArkanere 22:56, 27 November 2007 (UTC)

Well, you don't have to put up a list of every single change that ever took place. It's on a skill-by-skill basis, so any users who is familiar with the evolution of a particular can just add it. A mention here would make it possible for that such to write something about it. Why document skill balances and nerfs that have taken place? Well, same reason why we're documenting old and removed quests, previous special events, beta names, etc. - for the heck of it :D I'm basically saying that there's nothing wrong with letting people write something about it, as long as it does not disrupt or interfere with the normal use of the skill page. -- ab.er.rant 04:01, 28 November 2007 (UTC)

In that case it could be like the 'drop research', but with a subpage Skill/Skill changes. Then you put the link to the skill changes subpage somewhere in the notes or the infobox. MithranArkanere 13:32, 28 November 2007 (UTC)

Quick question

What was the reason we weren't going to use big icon's for skills, like those in the Sealed Deck. One reason was that we didn't have Nightfall, but Izzy said we would be getting them soon. ~ Kurd 14:01, 5 August 2007 (UTC)

Trivia

← moved to Guild Wars Wiki talk:Formatting/General

Title skills and progression template

So, I have a question regarding the formatting of title/rank related skills, aka Sunspear, Lightbringer, Faction, and many of the new GW:EN PvE skills. I know that people use {{gr|0|15}} to designate the skills for those with attributes and that makes sense, since the 0...12 progression is shown whenever you unlock a skill or hover over enemies' skills. However, I guess it fails, to some extent with title-based skills since the progression is different. For Sunspear skills, when you learn it, it's a 0..8 progression (since that's how the Sunspear skills progression works, if you flip it to an actual attribute, kind of like Signet of Illusions does). Does it make sense to keep the old template or should there be a new one? Personally, I like the old template only because it's easy to use instead of adding odd markup just to keep it the same, if only for the fact the same thing shows up when learning Sunspear skills. (Or a possible suggestion is to have the template change depending on the skill it's based off of, but I'm no wiki expert). It bugs me that it's not consistent, and Gorden Ecker seems to be adding the markup. If it is 0...12...15, it's easy to add at least new Spells in the PvE versions with a simple test of Signet of Illusions, instead of waiting for the max titles to come out (although it seems like it's going to max at 10, maybe with 8 in normal mode) Celaeris 04:46, 31 August 2007 (UTC)

Take a peek at {{Skill progression max10}}, is it what you had in mind? Chriskang created it a couple of days ago, so it still hasn't been applied to the various title track skills yet. --Dirigible 04:54, 31 August 2007 (UTC)

Ah that would be perfect! Is there one for max12 for faction ones? I guess the max8 for LB isn't so useful, since LB skills don't have green numbers. Celaeris 04:58, 31 August 2007 (UTC)

Took a closer look, I was wondering what was to be done for the actual green numbers that appear in the text, as opposed to the progression table. 0...12...15 for example. Nevermind, found out there's a {{gr2}} as opposed to {{gr}} Celaeris 05:05, 31 August 2007 (UTC)

GW:EN Blessing - format question

When updating Hunt Point Bonus I struggled for a uniform format to follow and frankly, couldn't find one. I used the skill box, because it seemed to fit better than the SS/LB box, but it really needs a special one and that's out of my realm of ability at the moment. Lady Chevon 18:32, 23 September 2007 (UTC)

I'm on it ;)reanor 17:47, 24 September 2007 (UTC)

Effects infobox

← moved to Guild Wars Wiki talk:Formatting/Effects

Small question...

...about acquisition: do we list all the trainers who teach a certain skill or just the first ones ? Let's say: trainer 'X' on Shing Jea Island in Factions offers skill 'A'. Knowing that skill offering is cumulative up until Michiko (Kaineng Center, 1st trainer for players from other campaigns), do I list trainer 'X' and Michiko, or trainer 'X', Michiko and every other trainer that offers this skill in Factions ? Erszebet 15:40, 17 November 2007 (UTC)

My first thought was to only list the first one, but seeing as Factions trainers aren't really linear in their lists (next trainer doesn't just offer all before and some new), that could be confusing. I think we should list all other trainers also, for Factions. - anja 11:19, 18 November 2007 (UTC)

Maybe something like

• Trainer X
• and following

? poke | talk 13:57, 18 November 2007 (UTC)

I agree with Anja. That works well, but only when it actually is all later ones. Backsword 06:18, 27 November 2007 (UTC)

I like poke's idea. For special cases, just add a follow-up note to say (except so-and-so in blah-blah). But generally, if I see Michiko listed, I'd just jump to Kaineng to grab it. I won't go somewhere later in the storyline to get it just to avoid Kaineng. And for cases where you can get a skill from different branches (such as Kurzick-Luxon, or Margrid-Master of Whispers, or local-foreign characters), just list both. -- ab.er.rant 06:30, 27 November 2007 (UTC)

I agree with Backsword, we should not make misleading generalizations. -- Gordon Ecker 06:38, 27 November 2007 (UTC)

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)

Beta icons

I found some of the beta icons of some skills:

Am i allowed to add them, or is it unnecessary? ~ Kurd 13:23, 2 December 2007 (UTC)

Documenting is never a bad thing. Go ahead.reanor 14:26, 2 December 2007 (UTC)

They can be added in the notes. Along with thins like the old behavior of skills like Othyug cry. MithranArkanere 22:10, 2 December 2007 (UTC)

Add a redirect on the images and a [[Image:Skill name beta.jpg|thumb|Beta icon]] or something like this below the infobox. poke | talk 22:14, 2 December 2007 (UTC)

Done and done ~ SCobra 14:12, 7 December 2007 (UTC)

Old Skool Heal sig looks so cool, but I guess it doesn't really fit with the warrior colour scheme. Lyra Valo 21:25, 12 December 2007 (UTC)

So making a texmod with these, they are so cool! --Lou-Saydus 00:37, 18 January 2008 (UTC)

pve-only parameter

The pve-only parameter has been altered to add a note in the infobox rather than categorizing the skill into Category:PvE-only skills, are there any objections to incorporating it into the formatting for all PvE skills? -- Gordon Ecker 07:55, 16 January 2008 (UTC)

No objections here, it is a good idea. - BeX 08:30, 16 January 2008 (UTC)

Agree, good solution. - anja 11:28, 16 January 2008 (UTC)

Does this mean that it doesn't auto-categorize anymore? Categories are the things that DPL likes most... --  (CoRrRan / talk) 13:07, 16 January 2008 (UTC)

No, this parameter was never used, since most of the skills were in subcats of the category it added. Aberrant already fixed the category in the single place where it was used, Signet of Capture. - anja 13:19, 16 January 2008 (UTC)

Parameters and categories are DPL friendly. Anything DPL friendly is user friendly. Makes automatic listing and skill updates much easier. So... it must be good. MithranArkanere 13:47, 16 January 2008 (UTC)

Hopefully this isn't jumping the gun, but I've gone ahead and modified all the Kurzick/Luxon skills to use the PvE-only flag. Looks like everyone's happy with it anyway. -- Hong 13:50, 16 January 2008 (UTC)

I wanted to make it autocat such that it places them in the proper pve-only campaign-based categories, and then have changed the rank-based categories to be a subcategory of a new category called title skills or something. And then I realised that I don't have the time for it so I opted for the simplest change. :) It'd be nice to be able to get rid of the manual campaign-based categories. -- ab.er.rant 00:34, 17 January 2008 (UTC)

Can you give me a bulleted list of what kind of ordering you want to achieve? I've made the [[Category:{{{profession}}} PvE-only skills]] (here), but I don't really get your comment on "get rid of the manual campaign-based categories". At the moment, the only PvE-only skills that use manual categorization are the profession ones, as far as I can tell. --  (CoRrRan / talk) 12:27, 17 January 2008 (UTC)

Eh sorry, I was actually referring to the manual profession categories :P those that divide the skills by profession in Category:PvE-only skills. -- ab.er.rant 13:17, 17 January 2008 (UTC)

Related skills - what's our goal ?

After the recent edits to Wild Strike etc (adding Mallyx's monster-only skill to related), I'm forced to bring this up here.
What are we trying to do with the section? On GuildWiki, the goal was to give people options of new skills to use. Using the new skill wasn't always feasible - as User:Extremeone has pointed out, a Paragon using Wild Throw isn't going to switch to Wild Strike - but it's still an option.
In general, GWW's articles have pretty much auto-conformed to GWiki's standard of "keep it simple, keep it useful." The latter is what we're concerned about here. Sure, I agree that Mallyx's monster skill is "related" to Wild Throw in that they both remove stances; they aren't that related, however, because you can't use one of them.
Even skills that are related in some aspects can have other, more important differences that separate them. See http://gw.gamewikis.org/wiki/Talk:Flail#Related_Skills for example. A user listed Shield Stance as related to Flail, because they both make you move 33% slower. Is that a similarity? Yes, it is. However, people aren't going to be looking for other ways to snare themselves. It's a similarity, frankly, that doesn't matter. Mallyx's Smash removes stances just like the other Wilds... but who cares? That information is not helpful to the player, especially not in an article about a skill.
Think about it; if you fought Mallyx and your stance tanking ranger or warrior got brutally beaten, are you going to go to Wild Strike and hope that you find what Mallyx used on you - or are you going to look at the Mallyx article and seek information there? Knowing that Mallyx removes stances is certainly important, but again, it's information that belongs in the article about Mallyx, not in the article about Wild Throw.
In this case, do we want to list monster skills in the Related section of normal skills, however similar they may be? I've said my piece on it already (1. the Related Skills section is for people to find other options to use, and 2. if people want to know about the monster skill, they're going to look up the monster using it, not player skills that do the same thing).

As a final thought, I have no problem adding player skills in a related section on monster skill articles. If someone sees Mallyx's Smash and says "holy hell, that looks powerful... can I do it?" they would be able to see player-skill options. Again, though... people aren't going to be looking at Wild Throw and wanting to know which monsters can strip their stances :/ -Auron 14:19, 1 February 2008 (UTC)

It wasn't added recently to Wild Strike, it was added on August 17, see here:[1] -Ë×ţřεмəόήє 14:47, 1 February 2008 (UTC)

That's nice, but my point still stands. -Auron 14:59, 1 February 2008 (UTC)

You are absolutely right there, Auron. We should only list skills which the player may be interested in. This is the same reason why I think we should never create DPL lists with combined player skills and monster skills or effects (see two sections above). poke | talk 15:35, 1 February 2008 (UTC)

I always thought that related skills are those with:

• Similar behavior.
• Plot-related. Like norn blessings and norn auras, or the effects of the orrian and Myst scepters, for comparation purposes.
• Proximity-related. Like all the Torment environment effects or the different monster skills of a creature. Why? Because a player may be looking for the best area to far lightbringers point for his profession, or looking all the skills monster have in an area to face them.

But in the case of monster skills I think we should not add monster skills in the related skill lists, but we should add player skills in both monster and player skills. For example, Unholy Feast in Life Vortex's related skills, but NOT Life Vortex in Unholy Feast's related skills. Why? Player may want to know 'how to do too that thing the monster does', but there is no need to know that a monster skill is similar to a player skill unless your are facing a monster that uses it.MithTalk 16:15, 1 February 2008 (UTC)

Exactly my point ~ SCobra 16:20, 1 February 2008 (UTC)

I've always considered the "Related skills" to finish the sentence, "If you're considering this skill, you may also be interested in _____." So yes, I agree there's no real use for monster skills in player skill articles, but player skills in monster skill articles are fine. - Tanetris 19:18, 1 February 2008 (UTC)

I don't mind to have it either way, but I think the points you put up makes alot of sense. - anja 19:26, 1 February 2008 (UTC)

Tanetris sums it up nicely. If anything, we are following GuildWiki's style so it's just the guidelines that need some clarification. The point about monster skills linking to other monster skills plus player skills should stand too. -- ab.er.rant 02:06, 2 February 2008 (UTC)

I agree with Mith above. --Xeeron 14:13, 2 February 2008 (UTC)

I think we all agree, can someone add it ~ SCobra 19:53, 3 February 2008 (UTC)

On what do 'all agree', because I don't see a consensus right away. As for my opinion on the matter: I 100% agree with Tanetris. --  (CoRrRan / talk) 17:27, 13 February 2008 (UTC)

Actually, if you read all the statements, no one is against the "Player Skills in Monsters Skills pages, NO monster skills in players skill pages". It doens't matter whom you agree with, we all say the same, XD. I just added the 'related in plot and localization', for things like related environments effects, like the Anguish or the Urgoz environment effects; or the Orrian and Myst scepters skills, that are related in plot. Just that. MithTalk 18:49, 13 February 2008 (UTC)

GWW and the Skill Descriptions

→ moved from User talk:Ab.er.rant#GWW and the Skill Descriptions

I always wondered about the Fact that in the Skill descriptions in this wiki and the Fact that it uses the max. Damage Values for an attribute Level of 15 where the maximum a Player can reach is 16?!? It confuses me somehow. I also think the ingame description is scaled from 0 to 16 too. So why are we doing this here? (Wasnt sure where to post it and thought long about it but in the end decided for your Talk :P If you know a better place move it and let me know about it :) ) SilentStorm 12:40, 9 March 2008 (UTC)

You are wrong in the assumption that it scales from 0..16. It is 0...15 for all regular (i.e. non-pve stuff) skills. That resulted in this wiki using 0..12..15 attribute tags. Also all skill update pages use 0..15 (and this comes from A.Net directly). --  (CoRrRan / talk) 13:41, 9 March 2008 (UTC)

Oh must've missed that just checked ingame and it scales 0...12 ingame. Its ok though just confused me ;) Thanks for Clearification :) SilentStorm 14:05, 9 March 2008 (UTC)

Yeah, there was a discussions somewhere about that. It's confusing, but you get used to it. On skill pages, the second green number is 12 attribute rank, I believe. Calor 16:10, 9 March 2008 (UTC)

Yep it is. Three Bolds in the Table and 3 Numbers. Plus it perfectly fits the Tables and Ingame Values. SilentStorm 17:14, 9 March 2008 (UTC)

When I was talking about 'scaling', I was referring to how the progression of the skills is. This is based on a 0...15 linear progression. Ingame, the skill descriptions are indeed shown as 0...12. The main reason for the 0..12..15 style is that A.Net provides skill updates in a 0..15 manner, and we also wanted to include the values for attribute rank 12. Hope this makes it clearer somewhat. --  (CoRrRan / talk) 20:41, 9 March 2008 (UTC)

Yep thanks :) SilentStorm 22:24, 9 March 2008 (UTC)