Template talk:Skill infobox/Archive 4

Skill history

Putting it into the infobox is handy and all, but I don't like how it says "Skill history NAME/Skill history"; redundant imo. And the first skill history box doesn't even look like the other boxes (links). And the question is, is it important enough to have a place in the infobox, rather than just in the trivia? --JonTheMon 03:46, 2 February 2010 (UTC)

I changed it :P –alistic 03:47, 2 February 2010 (UTC)

Well, if it goes in Trivia, then we have to tag every single page as we make them (unless we are going to use an {{ifexist}} in the Trivia secion) –alistic 03:56, 2 February 2010 (UTC)

Perhaps a <small> line under the infobox? But really, I'd like to get more people's opinions on this. --JonTheMon 03:59, 2 February 2010 (UTC)

I personally suggest we wait to add anything to the main skill pages until the project has completed more of a majority of the skill history pages. As it is, it is only available for some of the dervish skills and a few other miscellaneous skills. I don't believe the animation link was added until they had 75% of them completed. -- Wyn talk 06:36, 2 February 2010 (UTC)

Alright then, we'll add them to the main skill page later. –alistic 23:29, 2 February 2010 (UTC)

So remove that for now? --JonTheMon 15:11, 3 February 2010 (UTC)

Yup–alistic 16:19, 3 February 2010 (UTC)

Since, I didn't know about this discussion until now. I will show what was discussed on Figherdoken's talk page that two suggested. What do you all think? Kaisha 02:54, 26 February 2010 (UTC)

No, it should follow the model of the animations project and just be linked through the infobox. -- Wyn talk 02:56, 26 February 2010 (UTC)

Okay. Well, may I make a suggestion on the infobox? Have it say Skill history (in like under Campaign) or history and the "click to view". Just a thought that came to mind. Kaisha 03:04, 26 February 2010 (UTC)

Default icon location

Currently based on the name parameter, I was thinking of changing it to pagename magic word, as for cases where the article is disambiguated likely meaning the icon name needs to be too. Can anyone think of any issudes this may cause? Backsword 15:10, 4 April 2010 (UTC)

Issue could be those pages where the image already exists based on the name parameter but wouldn't work with the pagename word. I don't think there are that many pages where a custom image name is required, and I think it is easy enough to simply use the image parameter there. poke | talk 15:25, 4 April 2010 (UTC)

True about existing use, and I know of one such case, however there it is causing a naming conflict. Skill pages have high priority, so when they are disambiguated there is almost always an extensive articvle or disambig page at the base name. And this is quite common once one moves to monster skills and such, it is ionly the unlockable skills for wich it is highly unusual. Backsword 15:29, 4 April 2010 (UTC)

Modification to show more categories and sort options in the skill lists

My apologizes, I should still have been on preview, not save (fumbled click)... wanted to do things in order and had this talk with the dubbed template for people to check the changes, silly me. Anyway, the template was almost done (see [1] for a check), I will continue the tests on different skill infoboxes via the template Template:Skill infobox/sortmod : smarter and safer.

@Greener:didn't saw my mistake since it was my "should have been previewed" modification who broked it (missing end bracket near activation case).

--Leonim 10:18, 9 September 2010 (UTC)

Ok, the Template:Skill infobox/sortmod is finished, the category created (exhaustive list of sorting and searcheable categories in Category:Hidden categories) and everything is working as intended. Meaning the visual of the skills won't change, and only two new categories may show : Category:Instant recharge skills and Category:Instant activation skills. I'll let things as is for a few, and will come back to swap for the new template if shown bullet-proof.

Pµurpose : Pretty listing (DPL extension) will take advantage to have skills in premade categories, as well as curious and off-game users. The categories will be populated automatically on wiki bot request (at a later date).

--Leonim 13:08, 9 September 2010 (UTC)

I really don't see the point of having such a specific categorization. You can already perform DPL calls for those categories, it's just a lot harder. I think this will just clutter up articles with little-used categories. --JonTheMon 14:09, 9 September 2010 (UTC)

Hidden categories don't clutter pages, as they are not shown there (that's the actual point). And in fact, DPL won't be able to get all skills with recharge X due to it's 500 pages limitation. The actual purpose might be not that clear (I'm not sure who would actually want to look for that), but at least it offers possibilities we currently don't have, without adding additional problems. So I don't specially oppose this. poke | talk 18:40, 9 September 2010 (UTC)

Hidden categories make it more palatable, but ultimately my worry was that there would be pages for each of the possible categories. If it's only used as a parameter in some sort of template, I might be ok with that. --JonTheMon 19:02, 9 September 2010 (UTC)

(Indent reset) To see the weight of a category, you can check some infor from the game (sort skills by...), and lets take an example with a simple A/E PVP character and simply activation time : 40 Instant activation, 38 * 0.25¼s, 5 * 0.5½s, 25 * 0.75¾s, 100 * 1s, 41 * 2s, 5 * 3s and only one 5s activation time. Surely, there's not that many (by the way, I can't tell for sure with ingame tools) skills with long activation, but they are still worth their own category, meanwhile other categories will be quite crowded as they are cross-profession and cross-campaign.

About other less immediate categorizations, they are worth because they give us adaptability ("cause bleeding" and such are always welcome and were indeed forecast in the existing code), yet they wwere never used sadly (but I have time to do a one pass, slowly but sturdily ;)). I would finally add that having consistent top categories, allow easier "removal" from search lists (I'm currently clearing special skills article and the Category:monster skills alone is a mess to deal with, but the worse is that I have to know all subcategories to remove the whole... not very user-friendly).

Finally, I have a bunch of corrections (not upgrade) waiting to be pushed onto that template :

• lack of case control (on type) causing root categorization (Lift enchantment for instance);
• projectile spells not getting attention;
• projectile skills missing a category, and actually they were too be sortable by speed (unsure about that, nut that's how the doc hint at it);
• special skills lacking the broad category listing;
• self-reapplied skills not set, gramatical error in the old (and never created) category;
• 0 energy not showing as not an energy skill;
• 0 adrenaline not showing as not an adrenaline skill;
• range skill categories unproperly named (no occurence in "whats link there", so easy fix), as in game it is said "Half range skill", not "half ranged skill".
• removal skills not set, when a feature sought by many : like skills which remove stances or enchantments (or even a specific condition, but the template has its limit : Ranger's Antidote Signet has to be put into the "condition removal skills" only. I'll work on some text parsing (with the broken sign used in DPL for instance) if really needed;
• A lot of long-time missing categories, even if they were unused, like the "Skills which cause ..." (I'm proposing the "which cause" term over the "that cause" by the way).

--Leonim 17:48, 11 September 2010 (UTC)

Though I think some of the categories may be over-kill, I will admit that the lists you've been able to make are at least interesting. I have avoided most editing of skills and skill-infoboxes (seems Silver Edge is on top of those), but if these lists are to be usable, we'll need people to keep on top of them as the skills change. I wouldn't mind a project page set up for this (unless there is one and I'm blind), so that I can see the over-all structure of what you're doing. G R E E N E R 18:01, 11 September 2010 (UTC)

There is the inactive Guild Wars Wiki:Projects/Skills project, I left quite similar (but earlier) info there. Since it was inactive and old, I prefered to not dwell to much on the page.

Do you want me to create a project stub from scrath and summarize what really does this template (skill infobox) and what it can do (both with existing parameters and with a handful of new ones)?

• The visual side is quite self-explanatory : though a "morale boost recharge" icon would be a nice addition.
• As for the categorization based on the parameters, they are in the description of the "sortmod" variant. But if we're speaking of explaining the complete branching, it is more code made text.
• A better handle of special skills (a global listing coupled with subcategories like : disguise, mission, etc.) could not harm.
• Finally, you have the "extra" parameter proposal which covers a possible evolution (to help maintain many lists of skills more easily).

Depending on what is the consensus, there are two implementation paths : either swap for the proof-tested new version or modifying the existing one step at a time (globally lengthier and some temporary non-final, or totally bogus, categories will appear in the skill pages during the process).

• Step 1 : Bug corrections and category mismatch, but nothing critical.
• Step 2 : The existing template has a few inactive (I mean by that unused, partly or simply unfinish business) yet very interesting parameters (causeN and removeN, projectile, target), I'm not sure why.
• Step 3 : Cleaning the categories mess.
• Step 4 : Introducing the modified categorization code (availability of lists and sorts by recharge time, activation time, energy cost, adrenaline cost, sacrifice cost, range, removal effect and appplied effect).
• Step 5 (optional) : Adding new basic parameters covering a bunch of missing mechanisms like easily-interrupted, armor penetration, damage type.
• Step 6 (optional) : Adding the extra parameters (one form or the other).
• Step 7a : Refreshing skill pages (for categories to be automatically filled).
• Step 7b : Completing skill pages with values for those parameters.

But first and foremost, what is needed is to pick (or make some fictional) skill samples to test-proof either path taken; as I'm biaised (coding), I can't do that well enough. Is there a namespace and wiki naming guideline for, (or particularly suited, maybe "user"?) test pages?

--Leonim 02:47, 13 September 2010 (UTC)

For initial non-save testing, I preview an existing page with the test template. For more thorough examples, I make sub-pages that copy existing pages, but with your test template. For those kinds of pages, though, you might not fully implement the categories (use [ instead of [[), but that's up to you. --JonTheMon 02:53, 13 September 2010 (UTC)

I'd love the morale boost recharge. I've added the categorization for it, but couldn't find a working form for the icon in our current template. - J.P.Talk 12:17, 20 February 2011 (UTC)

Skill ID

I think the template should be changed so it is shown no matter if "| image" is being used..... If it's possible. - J.P.Talk 20:03, 25 November 2010 (UTC)

So, why would this be helpful and where did you want it to show up? --JonTheMon 13:32, 26 November 2010 (UTC)

Move your cursor over the skill icon on here and tell me what you see. Now do the same here. See?

Ofcourse the "| name" could be changed from Siege Turtle Attack to Siege Turtle Attack (Fort Aspenwood), but then it wouldn't reflect what it's called in-game. - J.P.Talk 11:18, 1 December 2010 (UTC)

Ok, I get the difference, so why do you prefer the ID over the skill name? --JonTheMon 13:56, 1 December 2010 (UTC)

What? No no no, over the image direction shown when hovering your cursor over the image. - J.P.Talk 14:14, 1 December 2010 (UTC)

Image direction? Can you be clearer than that? makes no sense to me. When hovering cursor above the mending pic I see "290" in the text window and when hovering over the seige turtle I get "image:Seige Turtle Attack (Fort Aspenwood).jpg". --File:User Chieftain Alex Chieftain Signature.pngChieftain Alex 14:44, 1 December 2010 (UTC)

And that's because image paragraph is being used, obviously.

My request is simply to modify the infobox to make the ID visible, even if the image paragraph is used. - J.P.Talk 15:37, 1 December 2010 (UTC)

Do you mean parameter instead of paragraph? Ok, so i'll re-ask my question: why to you want the hover popup to be the ID instead of the name? --JonTheMon 16:10, 1 December 2010 (UTC)

Yeah, sorry about that.

I don't know have you noticed, but the ID is what currently pops up. ID unset if the infobox is missing it. But only if image parameter isn't used.

I think this is a great way of having the skill ID in the infobox, without increasing it in size. Image parameter hiding the ID decrease it's usefulness. - J.P.Talk 22:03, 1 December 2010 (UTC)

I understand the behavior, I'm asking why you want it to show the ID. It doesn't seem like very useful information, since it's just a behind-the-scenes number. --JonTheMon 22:06, 1 December 2010 (UTC)

I don't know why this was added in the first place. I have no opinion why ID should be there. Maybe you should ask that from Backsword, he made the edit.

I just assumed this was something that was agreed upon and just went with it.

However i agree it's just behind the scenes stuff and won't mind abandoning it if people think it's unnecessary. - J.P.Talk 22:28, 1 December 2010 (UTC)

LOL asking backsword for an explanation. And really, if he does something you don't understand, it's probably not consensus, it just hasn't been noticed before. So, apart from "consistency" or whatever, what do we want? --JonTheMon 22:35, 1 December 2010 (UTC)

is-pvp and has-pvp variables

Can we get the "is-pvp" variable to call Template:pveversion in a similar manner to the "has-pvp" variable calling Template:pvpversion?

Also, "has-pvp = n" still calls the category Category:PvE versions of skills. G R E E N E R 23:01, 18 February 2011 (UTC)

I agree. It would make it practical like "has-pvp" - parameter is now.

One way could be the is-pvp value being the pve version of the skill.

Like: | is-pvp = Shadow Form

Though it would require going through all the pvp skills instead of just editing the template. - J.P.Talk 12:09, 20 February 2011 (UTC)

That's an interesting way to look at it. As for editing all the pvp pages, I realized that per my original intent, we would have to delete all of the current {{pveversion}} from their pages manually if we get the infobox creating it. G R E E N E R 20:14, 20 February 2011 (UTC)

Yeah, i somehow totally ignored the fact... - J.P.Talk 21:47, 20 February 2011 (UTC)

Requires recharge

I support setting up an icon to show/demonstrate that the skill requires recharge, but the +2% morale boost icon is (a) too large compared to the other icons; (b) misleading (the skills don't offer +2% morale); and (c) should probably appear below other icons.

Although changing just morale boost doesn't impact most skills, I think it's better to setup a sandbox version of the template for testing purposes and get other people's opinions about how it looks before updating.

I also think we should remove the icons from the other require-recharge skills until we agree on how to update the infobox.  — Tennessee Ernie Ford (TEF) 23:51, 13 April 2011 (UTC)

Here you go.

As for the "misleading" aspect, I honestly don't think it would be an issue (Considering that the recharge image is proceeding it.) - however removing the "2%" from the image (if even possible), may help. An alternative would be someone creating a green up arrow icon image to use instead of the generic morale boost image. It may help.

Finally, there's no feasible way to make that appear last without affecting other skills (And, resizing the image makes it not really necessary), unless you were to add an additional parameter to the skill info box template specifically for morale boost recharge skills, which would cause issues with categorizing. Ryuu - lol wiki 00:05, 14 April 2011 (UTC)

Thanks for setting up a sandbox for a skill; I think we probably also need to sandbox the template for testing.

I like your idea of using an alternative color to the recharge arrow (green works, I think, although red might be better). That's easier to implement than superimposing the recharge icon atop the morale icon (after removing the specific number). In case folks like seeing the Morale icon as-is, I've taken the liberty of reducing it to 19px (same size as inline icons) in the sandbox.

It wouldn't be hard to set it up to go last if we make requires morale boost to recharge a new parameter (instead of having it mixed with normal recharge as it is now). However, after reflection, that seems more trouble than it's worth.  — Tennessee Ernie Ford (TEF) 00:37, 14 April 2011 (UTC)

Maybe instead of showing a morale boost related icon, it would make more sense to show something that makes it clear, that it does not recharge. After all, those skills do not recharge, and morale boosts just recharge every skill. Mabye a simple would be enough. poke | talk 21:28, 14 April 2011 (UTC)

I like that better, especially if we can replace that (eventually) by superimposing the two icons.  — Tennessee Ernie Ford (TEF) 21:47, 14 April 2011 (UTC)

"...especially if we can replace that (eventually) by superimposing the two icons." — Tennessee Ernie

With something like this? Ryuu - lol wiki 23:14, 14 April 2011 (UTC)

I like that in lieu of the usual recharge icon. However, I was thinking more along the lines of (it takes me 2 rulers to draw a straight line, so try to judge this image on the concept, not the execution)  — Tennessee Ernie Ford (TEF) 23:32, 14 April 2011 (UTC)

Touched it up.

I suppose I'll start looking at implementing it into the template via sandbox, now. Ryuu - lol wiki 23:50, 14 April 2011 (UTC)

(Reset indent) Done. An example can be found here. If it's worthy, then the updated template can be found here. Ryuu - lol wiki 00:18, 15 April 2011 (UTC)

That's kinda ambiguous. Like, yes, it's a grey version of the recharge icon, but it doesn't say much. There needs to be a little more...--JonTheMon 00:33, 15 April 2011 (UTC)

What would you suggest, then? Ryuu - lol wiki 07:39, 15 April 2011 (UTC)

Poke's suggestion of "this skill doesn't recharge" or TEF's mini-boost icon. Perhaps we can make a tango morale boost for this? --JonTheMon 12:41, 15 April 2011 (UTC)

Could the morale boost and the recharge icons be combined into a single icon? Like a recharge icon with a morale boost background that is twisted so the arrow of the recharge icon is the triangle of the morale boost. MithTalk 01:13, 6 January 2012 (UTC)

Upkeep

I boldly changed the upkeep icon to File:Tango-upkeep.png, since that is consistent with the rest of the wiki's current usage:

1. It was the only icon (in the infobox) using a non-tango style;
2. {{upkeep}} uses the tango version (and both it and {{skill infobox}} might appear on same article)
3. It stood out next to the other icons.

If someone feels strongly that this was a bad move, please revert and I will volunteer to setup the necessary discussions/links to reach a community decision. – Tennessee Ernie Ford (TEF) 20:35, 18 August 2011 (UTC)

Missing Concise Description

Following up from /Archive 3#concise description parameter and more recently here, I cannot tell whether a decision was ever reached in regards to how this might be fixed. Would it be possible to make a certain input (let's say "none" or "history") make it appear as if there isn't anything to display but disabling the automatically added category? Just using a keyword would allow us to decide whether one was truly missing or if it's left out because the skill didn't have it then or the template is being used elsewhere. There may also be a reason for keeping it: so that skills that historically didn't have concise descriptions are represented. ~FarloTalk 07:17, 21 October 2011 (UTC)

Or we could see if Zerpha (recently back to gww) could mine some concise descriptions for us thus removing any need for the cat? :P --File:User Chieftain Alex Chieftain Signature.pngChieftain Alex 15:26, 21 October 2011 (UTC)

Ah I see the problem: so we can't have concise descriptions for skills that changed.

Yeah we could add another parameter that automatically tags the page unless specified; like if "concise" exists AND another new parameter like "| concisetag =" is equal to "no", then tag is with Category:Skills missing concise description.

I can however see that it already checks the namespace is correct, and I don't have enough experience in coding on the wiki yet to know what the phrase for #if with two functions is.--File:User Chieftain Alex Chieftain Signature.pngChieftain Alex 15:37, 21 October 2011 (UTC)

As far as I can see, this does only affect a) Skill Histories and b) skills removed from the game. In either case, we will never be able to add the concise description, since it isn't available any more. Skills currently in the game will always have a concise description. Correct?

Both skill histories and removed skills should have "categorize = n" set. In other words, I'd simply repurpose that parameter to hide Category:Skills missing concise description as well. Objections? Tub 12:45, 30 October 2011 (UTC)

self-targeting skills: no such thing

Current situation and proposal

This wiki currently list several skills as "self-targeting". They are all listed on Self-target (warning, huge page, long load times). That page contains three kinds of skills (plus the oddball here and there):

1. Skills that always apply an effect to the caster, like Healing Signet, Aura of Restoration, Flash Enchantments, ...
2. Skills with point blank AoE, like Inferno.
3. Partywide buffs like Aegis or "Fall Back!".

There is the question whether these skills are actually self-targeting or whether they target nothing at all. Ingame-references found so far include:

• Well of the Profane, Shadow Shroud, Shame and Boon Signet. They do not consider any "self-targeting" skill to actually target the caster. All have some intricate phrasing to add the word "target" in the description, i.e. "cannot be the target of enchantments" instead of "cannot be enchanted".
• Signet of Mystic Speed talks about self-targeted enchantments, and triggers on Aegis etc as well. This skill has been added very recently, months after this wiki started documenting skills as self-targeting. Seeing other skill descriptions as written by the current live team, this may not be the best source for a coherent documentation of game mechanics.
• Divine Favor heals the caster on "self-targeting" monk skills as well. The official description is not very formalized and does not talk about "targets" at all, so it may not be very conclusive.

That makes four strong points towards "they target nothing" and two weak points towards "they target the caster".

This wiki is currently using both terms to refer to the same set of skills. Many older articles refer to "untargeted", while the introduction of the target= parameter to this template has given rise to documenting them as "self-targeted". Those are two names for the same thing, and for consistency we should get rid of one of the terms. Preferably the one that causes confusion.

The template description currently says:

"Valid targets of the skill. Guessed from the skill type if not set. Valid values are none, self, foes, location, party members, allies, other allies, animals, corpses, minions, spirits, summoned creatures and dead party members."

(I'm not sure if "none" refers to the unset parameter or the specific value "none"; currently there doesn't appear to be a skill with "target=none" set.)

My proposal is to replace the term "self-targeting" with "untargeted" on this wiki.

To do so, I propose changes to the template that will:

• add a "target = untargeted" to the description and remove "self" and "none" as values.
• Have template logic that categorizes them into "Untargeted skills" instead of "Skills that target untargeted".
• All skills that are mistakenly set as target=self will be forced into that category as well.
• Adjust the target-guessing to use the new category, too.
• Delete Category:Skills that target self and Self-target.

Opinions?

Also, if anyone can remember the discussion that lead to this edit (i.e. the introduction of the target= parameter and others), please provide a link. It's.. somewhat messy. Tub 18:53, 28 October 2011 (UTC)

/edit: clarified proposal Tub 18:57, 31 October 2011 (UTC)

Discussion

Quick Reference

Category:Skills by applied effect

Category:Skills by range

Category:Skills by target

Category:Skills by Area of Effect

Category:Skills by cause effect

Category:Skills by prevent effect << requesting new "prevents1" → "prevents5" category

Category:Skills by required effect << requesting new "requires1" → "requires5" recategory

Category:Skills by removal effect << requesting additional "removes3" → "removes5" (see Contemplation of Purity)

Exchanging "none" for "Untargeted skills" would indeed help. However there are skills that specifically states in their detailed/conscised description with You gain.... Also, "self-target" matters in relations to flash enchantments, signet of mystic speed, orders build, etc. Perhaps a more precise distinction needs to be made on what constitutes as a self-target vs. an untargeted skill? --Falconeye 20:14, 28 October 2011 (UTC)

Ok, Signet of Mystic Speed complicates things, because now the ingame descriptions contradict themselves. Are you aware of any other skills or mechanics that specifically talk about targeting, besides SoMS, Well of the Profane and Spell targeting prevention? Maybe we can find something coherent or at least decide which skill is the oddball skill that doesn't fit.

I did a few quick tests, and SoMS appears to affect both targeted enchantments targeted at yourself as well as like Aegis, Order of Pain or Eternal Aura. I don't think the game has any distinction between what you call "self-targeted" skills and I call "untargeted" skills, it's just a matter of picking the term that represents the game best and avoids confusion.

Whether "You gain..." doesn't matter with respect to targeting. Target is a specific ingame term refering to the thing you had selected while casting the spell. It does not refer to the entities affected by the spell; that's an entirely different matter. For example, Shadow Walk targets a foe, but affects only yourself, while Ancestors' Rage targets an ally, but affects only the foes around it. (alright, it does place an effect on the ally, but I can't come up with a better example right now)

For clarity of communication, it's important not to confuse these two. Tub 21:17, 28 October 2011 (UTC)

Shadow Shroud might be of interest in this context, the prevention works like Well of the Profane (I'd say). – 21:52, 28 October 2011 (UTC)

I agree that untargeted is what skills that do not require a target are, even if they solely affect the user. As for SoMS, the targeting of the user is a key aspect, not a target classification; it doesn't explicitly mean it has to be a "self-targeting" enchantment in the sense that it must only affect the user. The description is also from a much later stage in development, easily overlooked in terms of consistency on ArenaNet's part. If we go by Tub's proposed changes, that still leaves the current description of Flash enchantments. As per my bug report post on the official forums, Flash enchantments can not be self-targeted if Well of the Profane and Shadow Shroud are not bugged skills. One option excludes the other, and vice versa. - Infinite - talk 23:41, 28 October 2011 (UTC)

How could I forget about Shame? It prevents spells targeted at allies, and I know it doesn't trigger on several skills documented as "self-targeting" on this wiki. Is anyone aware of counter-examples? My whole friendlist is offline at the moment, so I don't have anyone for more extensive tests.

So far, it appears we have 3 skills vs 1 saying that these skills are not targeted at all. Tub 13:06, 29 October 2011 (UTC)

Untargeted skills can be the "official/default term"; while self-target skills can be the concised/unofficial term reserved for all things relating to those quirky SoMS/WotP/SS/STP/Shame/kitchen sink/etc. --Falconeye 20:35, 29 October 2011 (UTC)

We should only use non-official terms when the official term is more confusing than unofficial terms. That said, untargeted is far more precise (and concise), as self-targeting implies that your target must be yourself in order for the skill to work. Konig/talk 19:45, 30 October 2011 (UTC)

fun times you guys | 72 | 23:48, 30 October 2011 (UTC)

Koenig: note that "self-targeting" is not an official term in the sense that it's used on the wiki. Not a single skill is described as being self-targeted by the game. Most official uses of that phrase are used to denote something entirely different, the distinction between "can target allies" and "can target other allies". So it's not a question of official vs. unofficial term, but a question which inofficial term to use. Tub 14:52, 31 October 2011 (UTC)

(Reset indent) Note that most skills choose the target automatically when no target is selected. That is because how targeting woks in GW. All skills have a target, but many will pick it automatically under certain circumstances. For example, 'point blank AoE' skills use the caster itself as point of reference (Heal area and Healing Ring are good examples, since you can see that it applies Divine Favor to you, and Divine Favor applies extra healing to the target), and skills like the Conjures affect the caster always, no matter what you are targeting, and some skills target the valid target closest to the current target when the a valid target is not selected, I think Ancestor's Rage does that. The skill descriptions don't state this clearly, because they only describe the intended behavior of the skill, not what the skill actually does to create such behavior. What I mean is that "Skills that do not require you to target anything" is not the same as "Skills that do not have a target", because all skills have a target. MithTalk 11:49, 31 October 2011 (UTC)

You've noticed that all targeted skills use the target as a point of reference for their effects. You've further noticed that all skills have a point of reference for their effects, and you're now concluding that this point of reference must be the target. That's not only a logical fallacy, it also fails to consider skills like Shield Guardian which may have up to 8 (or 12) points of reference for their AoE-heal. Are you saying Shield Guardian has 12 different targets?

Your point about Divine Favor is appreciated though. Although it does not explicitely talk about targeting, it somehow implies that you did cast Heal Area at yourself. This wiki documents since may 2009, that "Untargeted skills heal the caster", which predates the categorization of spells as self-targeted on this wiki. The other wiki talks about an exception for "untargeted" skills as well. Apparently that was the accepted standard before the target=self parameter was introduced to this template.

Current list of evidence from the game, saying that Skills, whose effects are independent of the selected target, are..

• ..not targeted at anything: Well of the Profane, Shadow Shroud, Shame (all mention "target" explicitely)
• ..targeted at the caster: Signet of Mystic Speed (relatively new skill), Divine Favor (does not mention "target")

Game mechanics that relate to targeting, but do not make any points about the issue at hand:

• Mistrust, Guilt, all skills granting Spell targeting prevention.

Any more? Tub 14:52, 31 October 2011 (UTC)

(Edit conflict)

Is there *any* skill which specifically requires you to target yourself to use it? AFAIK; no. The term "self-targeting" is found on 1 skill (recently changed; older standards could have easily been overlooked when writing the descriptions), which actually stands for enchantments applied to oneself. Since you never (again, AFAIK) have to actually target yourself, the term is redundant and should be avoided. Self-targeted doesn't exist; applied to self does.- Infinite - talk 14:38, 31 October 2011 (UTC)

All this semantics makes my head hurt, but you guys should consider this: skills may be programmed to automatically target the caster ("self") if self is a valid target and the player's target is not a valid target. What I'm getting out of this discussion is that such an effect may be different from automatically applying the skill to self in said conditions, but... -- Armond Warblade 15:23, 31 October 2011 (UTC)

In response to Tub, Divine Favor has a note on the page stating {quote|Untargeted spells heal the caster. This includes spells which do not affect allies, such as Kirin's Wrath.}} Quite frankly, only SoMS is the odd one out in this issue.

As for Armond's theory, that would make self-targeting a "behind the scenes" mechanic instead of a skill parameter. In that case "self-targeting" should still be avoided, unless explicitly talking about this auto-correction on the game's part. It is no value any skill can have, but instead a scripting matter which changes targets for a skill when needed (examples are flash enchantments when targeting an opponent and offense-oriented skills when targeting an ally).

Aside from SoMS, there is not any mention of self-targeting in the entire game. The point blank area of effect article mentions "when self-targeting" but that is also incorrect: those 3 skills are PBAoE skills; they are not always around the *user* but they are always are around a *target*, which is what point blank means. Naturally those 3 note can be dropped and the definition of PBAoE updated to its correct state.

Finally we have the issue of "what if there *is* self-targeting" at hands. This would mean that all skills that apply an effect solely on the user would be self-targeted skills? And if yes, shouldn't all enchantments that follow that behaviour be unusable within a Well of the Profane, or under the effects of Shadow Shroud? The answer to the latter question would be yes, but since they are useable, the first question can only have no for an answer.

Conclusion; there is no such thing as self-targeting and the description for SoGM should be reported on the official forums for having a term error (and changed to "Your next 1...3...3 enchantments applied to yourself cast instantly."). - Infinite - talk 17:42, 31 October 2011 (UTC)

Evidence vs theory (self-targeting vs caster-area-of-effect)

There seem to be two arguments:

1. Some skills are self-targeting.
2. There are no self-targeting skills, but there are skills that create an effect on just the caster. (I would refer to these as skills with a caster area of effect ...or something more euphonious.)

This is easy to test: self-targeting skills (#1) can be prevented by skills that cause effects on targeted skills. For the purposes of argument, I think ANet's descriptions (long or concise) are irrelevant. We already know that they screwed up descriptions for Greater Conflagration and a lot of mesmer interrupts (many have an effect regardless of successful interruption, but the descriptions imply a dependency).

In the meantime, let's hold off on creating new categories or changing the skill infobox until we understand the mechanics behind this. (I'm going to ask that we delete the relevant changes to the wiki for now.) – Tennessee Ernie Ford (TEF) 15:46, 31 October 2011 (UTC)

See my response just above this section, no need to repeat myself. - Infinite - talk 17:42, 31 October 2011 (UTC)

TEF: I've clarified the proposal since I think you're refering to a slightly different thing. This isn't just about skills that always apply an effect to the caster.

Which "relevant changes" are you refering to that'd need deletion? I've replaced self-targeted with untargeted in two locations and done a (mostly unrelated) cleanup of target, but that's nothing that'd cause trouble (doesn't even create more inconsistencies than already present), and it'd be reverted, not deleted either way. Tub 19:07, 31 October 2011 (UTC)

Hypothetically, how would Vow of Silence interact with untarget/self-target without the You cannot cast spells clause? And can anyone from Anet help clarify whats official vs. what is error? --Falconeye 21:36, 31 October 2011 (UTC)

@Falconeye: Let's worry about documenting actual behavior without worrying about hypothetical cases.

@Tub: yeah, you're probably right that I was responding to recent comments rather than your proposal (updated); it's kind of lose in the WoT (i.e. I recommend that you start a new section with the new proposal, since it's roughly based on everything above this post). (I was also responding to recently created categories that are not directly related to this convo — those also fail to take into account several ongoing conversations or various existing naming scheme already in play.)

I don't have a problem with untargeted vs selftargeting as terminology. (Again, as long as there's no evidence that buff-target, punish-target, or target-prevention skills affect this class.)

I think it's too easy right now to confuse three similar ideas: target (the direct object of a skill), range (the distance to a target), and area-of-effect (the radius surrounding a target or surrounding the caster if there is no target). But ANet doesn't always strictly apply our definitions (outside of skills, there's the obvious example of a pvp-flux in the player-vs-AI zaishen challenge), so we're going to encounter odd exceptions from time to time and deal with them as best we can. – Tennessee Ernie Ford (TEF) 22:21, 31 October 2011 (UTC)

The thing is, skills are not consistent. From what devs have mentioned in the wiki, we know that skills are not 'composed' but coded, and so many things must be set manually, like some interactions between skills and attributes. That's why sometimes skills do not interact with each other even though they were supposed to (until they fix such bugs), and how some skills have weird behaviors that do not match their type. All skills target something, since they will all either affect a single target or have a certain area of effect. The 'target' the skill selects is used as point of reference of that area of effect. Without that target, the system will not know where to apply the effect. When a warrior uses a shout that affects all allies within earshot, the point of origin of the Within Earshot AoE the warrior himself, but that doesn't mean that you have to target self, the skill picks you as point of reference by itself. But the way skills behave when no valid target is selected is different between skills. Many will completely ignore the selected target and apply the effect centered on the caster; some will look for the closest valid target to the selected target and apply the effect in that creature (that may include self, like with many monk healing spells); many will not target something automatically and return a red error message when the target is not valid. Some will do unexpected things that do not match correctly the skill descriptions. Some will trigger certain things when they the ones doing the targeting, as if you were the one that targeted, some will only trigger those things when you must be the one picking the target. Because of that, you can't make a common rule for all skills.
There's one way to note this, though. It's by separating 'target' into two values: What the skill aims for, and what the player can target for the skill to get a point of reference. These two things combine in all possible cases we currently have.
Skills that apply the effect directly on the caster do not have a required target, and the default target is 'self', so you never have to target self to get those effects applied on you. The skill 'aims' to self, but you don't have to target anything. MithTalk 12:56, 26 November 2011 (UTC)

Can we call it yet?

Boon Signet is another skill that talks about targeting, and it doesn't trigger on untargeted/self-targeting skills either. I've edited it in above. There's now been ample time to give further evidence for one interpretation or the other, I think we've assembled enough examples by now to call it.

Based on this discussion, it's clear that many people have a strong preference to one term or the other, and a change in either direction is going to hurt feelings. But since it's important for this wiki to be clear, concise and consistent in its communication, we really should go ahead and purge one of them. Possibly documenting the other term and linking to this research, but not using it.

The results of our research (as documented above) is that the ingame documentation (and especially older documentation, both ingame and on this wiki) consider these skills to have no target. The term "self-targeting" arose sometime, but we have been unable to track down it's exact introduction - it may have been during the changes to this template, but maybe it has been older. In either case, no discussion for introduction of the term has been found, it just started being used somehow.

As such, I think we should go ahead and do the changes as proposed above. I won't have time to do it during the next few days, so if there's any last-minute evidence, technical issues with the proposed changes or anything else that would prevent us from going ahead, now's the time to speak up. Tub 11:53, 17 November 2011 (UTC)

Self-targeting probably arose out of familiarity with the general targeting system. It's also substantially easier to code a skill to target yourself than to code it to affect the area around you without targeting anything. Just my two cents. -- Armond Warblade 15:43, 17 November 2011 (UTC)

I think self-targeting can go now, as should we inform the live team about this term and why the only skill mentioning it should have its descriptions rephrased. Furthermore, all instances of "self-targeting" on this wiki should be altered to "applied to self" or similar phrasings. That should conclude any possible confusion and inaccuracy. - Infinite - talk 16:42, 19 November 2011 (UTC)

the changes are done

The wiki will need some time until all pages are recreated and properly moved from Category:Skills that target self to Category:Untargeted skills. The old category needs to be deleted once that's done.
If you find any mentions of "self-targeted" on this wiki, feel free to edit them away or link the page here (if in doubt about the proper mechanics). This is also a good place to mention any technical difficulties that popped up due to the change. Tub 11:33, 22 November 2011 (UTC)

Doublecast

Will this be classified as untargeted (self-target). If it works the way I think it does, then Empathic Removal (& others) could be an example of how this skill type would work. --Falconeye 20:53, 9 December 2011 (UTC)

With what we know to-date, it should be classified as targeted (e.g. you and target ally are enchanted...). Be careful not to confuse the area affected with the target. – Tennessee Ernie Ford (TEF) 21:08, 9 December 2011 (UTC)

Formatting glitch

The infobox with elite flash enchantments looks untidy ATM. The Type entry doesn't fit on one line, and when it wraps, it overflows into the Campaign entry—check out Pious Renewal, for instance. This could be solved by displaying "flash enchantment" instead of "flash enchantment spell". -- Hong 09:19, 27 November 2011 (UTC)

Works fine for me on Firefox and Chromium, the type is displayed on one line. Which browser are you using? Tub 19:21, 27 November 2011 (UTC)

I'm using IE9 and getting this issue too. (to clarify the the "elite flash enchantment" is on one line, then "spell" is on a new line with the descenders touching the top of "Nightfall") File:User Chieftain Alex Chieftain Signature.pngChieftain Alex 20:19, 27 November 2011 (UTC)

It looks fine for me in Chrome in the default font size but if I increase or decrease it for the page I get the same effect mentioned. --Valshia 20:30, 27 November 2011 (UTC)

The trouble is that the infobox is given a fixed width (20em), which may be exceeded for longer text depending on your fonts.

I suppose we could insert a workaround for people with larger font sizes, to prevent browsers from adding a linebreak, but a tiny change like that will result in the wiki recreating every single skill page, slowing down the wiki for several hours. I'm not sure the glitch is severe enough to warrant that.

On the other hand, we could also just make the infobox wider, or remove the fixed width altogether - let the browser figure it out, they're usually quite good at that.

Though both are somewhat invasive changes for a glitch that's rarely encountered.. Tub 23:20, 27 November 2011 (UTC)

(Reset indent) {{Effect infobox}} has a similiar issue as seen on Sugar Rush (long). --Silver Edge 05:34, 29 November 2011 (UTC)

Another Ugly Formatting thing

Applies to: Resurrection Signet, Sunspear Rebirth Signet & all of the celestial skills. Problem: the text "morale boost" is shown on two lines, and is very ugly. File:User Chieftain Alex Chieftain Signature.pngChieftain Alex 18:08, 4 December 2011 (UTC)

So how do you propose we fix this? Making the infobox wider would be a poor choice, and decreasing the font until it fits into one line would make it unreadable. Is there a shorter text and/or image we could use instead? Tub 00:29, 5 December 2011 (UTC)

There was similar convo about this a while back (someone decided to update the icon, iirc). Here are a couple of other possibilities:

1. Use a different color icon (maybe counter-clockwise instead of clockwise).
2. Use .
3. Use the recharge icon with a stylized + (similar to the one from morale boost), either side-by-side or the + superimposed over the recharge symbol.
4. Use a more noticeable cross, e.g. ╫ or ┼.
5. Any of the above with mouse-over text, Requires a morale boost to recharge (or something along those lines).

I don't have a particular preference, but I think any of the above (or something else) would be preferable to the status quo. – Tennessee Ernie Ford (TEF) 00:40, 5 December 2011 (UTC)

I believe the convo you speak of is the #Requires recharge section above. --Silver Edge 08:26, 5 December 2011 (UTC)

Exhaustion

Do we want a fix in place now for future changes to exhaustion as per the leaked skill updates? --JonTheMon 19:46, 9 December 2011 (UTC)

We might as well start working on it now in a sandbox. – Tennessee Ernie Ford (TEF) 20:01, 9 December 2011 (UTC)

Preview User:JonTheMon/Sandbox/Template/Skillinfo on a skill page and change "exhaustion = " to a number. --JonTheMon 20:19, 9 December 2011 (UTC)

That should probably default to 10 exhaustion if "y" was entered (to avoid changing all those skills), but we'll have to see how it looks ingame before deciding on the proper layout for the wiki.

{{#ifeq:{{{exhaustion}}}|y|10|{{{exhaustion}}}}} [[Image:Tango-exhaustion.png|Causes Exhaustion]]

Tub 01:09, 10 December 2011 (UTC)

There aren't many skills that cost exhaustion, so after the update, we should remove "y" as a valid option and replace them with 5s or 10s. – Tennessee Ernie Ford (TEF) 01:35, 10 December 2011 (UTC)

Well, I don't think that y=10 should happen, since that could become inaccurate, and it really isn't a good assumption to make. If we leave it at y=blank, then it will be visible that something needs to be updated. And I'm not really sure why you would say that exhaustion really isn't a cost, because it sorta is. It's a "penalty" for a skill, but that almost effectively acts as a cost. As such, while it may be inaccurate to leave "y" as a valid option, it's closer than straight-up removing it, imo. --JonTheMon 14:20, 10 December 2011 (UTC)

I apologize, I was unclear — we agree that we can treat Exhaustion as a resource cost (sort of an energy cross-breeding of Deep Wound and Sacrifice). Since less than 20 skills cause exhaustion directly, it won't take significant effort to update them all. Because, in effect, there no longer will be a default value, we should explicitly use exhaustion = 5 <or> 10. Once we do that, there's no reason to keep y as a valid entry because it's misleading and removing it as a choice will allow us to be able to easily see if a skill (or skill history) was correctly updated.

Regardless of how we handle that, we should probably also consider whether {{skill table}} (and associated templates) should include exhaustion as an option (similar to how we handle Sacrifice). – Tennessee Ernie Ford (TEF) 16:52, 10 December 2011 (UTC)

Yeah. Now it's like energy. There's a set of possible values, and it can take any of those. There's a category of skills that cause exhaustion. So it shouldn't be that hard to update them all manually after the info-box is updated. MithTalk 00:23, 6 January 2012 (UTC)

Rats. I thought we'd get a developer preview, which would give us 2-3 weeks to sort this out. – Tennessee Ernie Ford (TEF) 00:44, 6 January 2012 (UTC)

Template:Skill table needs to be changed to display the number of exhaustion. --Silver Edge 02:33, 6 January 2012 (UTC)

Forgot to mention that I've fixed those. Unfortunately, there's a large and undocumented number of row formats, and I'm not sure which of those are in use. I adjusted both the one documented as being the default, and then the one that was actually the default. Since I'm not in the mood for cleanup duty, I'll just leave it at that. If further formats require updating, just ask. Tub 04:06, 6 January 2012 (UTC)