Template talk:Skill infobox

Archive

---

• 2007 Fed - Apr
• 2007 May - Dec
• 2008 - 2009
• 2010 - 2011

Fractional activation times

We now have skills that recharge in 1.5 seconds: how do we want to display them in the infobox?

1. 1.5
2. 10.5½
3. 1¹/₂
4. 1½ (Temporary convention while we decide.)
5. Something else?

– Tennessee Ernie Ford (TEF) 00:51, 6 January 2012 (UTC)

Options #1 & #3 look best on my browser. --Falconeye 06:47, 6 January 2012 (UTC)

Shouldn't we create a template called {{1.5}} or {{3/2}}, similar to {{1/2}}, {{1/3}}, {{1/4}}, {{2/3}}, {{3/4}} and {{3/8}}? Those have some extra code for proper sorting in skill tables.

Example #2 looks ugly due to two sideeffects of {{1/2}}; it adds a space and enlarges the font size for the fraction.

For me, 4 looks best. Using the proper unicode-character over manually faked fractions is always preferable.

Note that (for consistency) we should not give units, i.e. drop the "s" at the end. Tub 12:57, 6 January 2012 (UTC)

It should be option 4, because it looks like in-game, but it should get rid of that "s" --Kyx 15:38, 6 January 2012 (UTC)

The s was added to give a sense of scale (since the value will appear in skill-list table rows, not just the info box). I've removed it from the options above to avoid any confusion about what is proposed for the infobox. – Tennessee Ernie Ford (TEF) 16:15, 6 January 2012 (UTC)

We should create {{1.5}} and {{1 1/2}} and {{3/2}} (probably all redirects to a single template) for proper sorting. Maybe (probably) we should also fix {{1/2}} et al so that they use unicode (there's also some weird spacing issues with the existing templates). (For what it's worth, #4 also looks best to me — it renders the display using native font data rather than a kludge, which should mean that it will look right to the greatest number of people across a wide variety of browsers). – Tennessee Ernie Ford (TEF) 17:01, 6 January 2012 (UTC)

Morale Boost Recharge

Mind if add to the recharge section for skills where it's relevant? "morale boost" typed out looks ugly. Open to a better/new icon as well. ~FarloTalk 05:52, 6 January 2012 (UTC)

See the #Requires recharge and #Another Ugly Formatting thing sections above. --Silver Edge 06:24, 6 January 2012 (UTC)

(Reset indent) Old I know, but I put in a special case for morale boost which causes it to display inside a whitespace-nowrap with a left margin of 32px. -Chieftain Alex 00:01, 13 November 2013 (UTC)

Temporary

Some special skills like the Celestial skills, the two nightfall mission skills, the norn quest blessings, and the skills granted by disguises, forms and effects that change the skill bar are 'temporary'. Meaning that you get to use them, but you don't get to keep them. Could a new parameter (e.g.: | temporary = ) be added for autocategorization? That way, a distinction could be made between skills that one get to learn and keep in the the list of 'common skills' could match the in-game list of common skills found in the skills and attributes panel, by removing those that are 'temporary', or make a new list with just the skills players can actually learn. MithTalk 08:34, 3 April 2012 (UTC)

There's four levels of skill availability:

• unlockable skills, like the regular profession skills we all know
• learnable skills (but not unlockable), which are the PvE skills that can't be used by heroes.
• player-usable skills (which can neither be unlocked nor learned), access is temporarily given by disguises, environment effects, bundles etc
• non-player-usable skills, a.k.a. monster skills

Maybe we can find a coherent way to deal with these that doesn't just slap on another parameter for a corner case? Extending the special = parameter perhaps?

I'd also like to see proper categories based on availability. We currently have situations where temporary skills creep into our skill tables in unwanted places, proper categories would allow us to precisely filter those in the DPL queries.

That said, I'm not too well informed about the current parameters or categorization, so maybe I'm just being ignorant here. Tub 10:06, 3 April 2012 (UTC)

Well, for the "unlockable" part, we already have the PvE and 'special' properties. If a skill is 'special', it can't be unlocked nor learned, but it still may be equipped, if Special is not "Monster". So a 'temporary' skill is a special skill that is not a "Monster" skill:

Not special, not PvE: PvP unlockable skills.

Not special, PvE: PvE-only skills.

Special=/=Monster, not PvE: PvP bundles (i.e.: Seed of resurrection and Entanglement)

Special=/=Monster, PvE: All other special skills players can use (e.g.: Junundu, Celestial skills)

Special=Monster, not PvE: Monster skills used by NPCs in PvP

Special=Monster, PvE, PvE: Monster skills used by NPCs in PvE

Maybe we could simplify all of this, but as I can see it just adding a 'temporary' parameter would do the trick for now, to have a common name for all special skills players can use. MithTalk 10:38, 3 April 2012 (UTC)

How does Sky Net fit into this? Its both a #3-Special skill and a #4-Monster skill. --Falconeye 06:45, 5 April 2012 (UTC)

Hm... if logic doesn't fail me, it would be like this: "Monster skill" is the original official term for all skills used by monsters that players won't be able to unlock, or learn in trainers or from quests. A few skills, not even close to all of them, have a (monster only) in the description. That's from where we took the name. But then they gave us skills from yuletide and Junundu, we didn't use the name for those, probably because players can use them, and so calling them 'monster skills' could be confusing. We started calling those simply 'common', until there were a lot of them, and they added also common PvE skills and they started getting mixed with all of them. So we came up with the "special" parameter to separate them. The special parameter set to "monster" was used for monster skills, and set to other terms for skills that can be used by players. SkyNet started as a Monster skill, but then it was added to a temporary build. This makes the skill no longer a "monster skill" but just like "Snowball" a special skill players can use, and monsters happen to use too. The same will happen with any skill that is like that, like the celestial skills that Henchmen can use. Since it started as a monster skill, one can be reticent to change it to "special->Golem disguise", but I don't think we should, since changing it will make it more consistent with other skills. MithTalk 15:15, 5 April 2012 (UTC)

I think now that the temporary parameter is not needed. My problem were the temporary skills from the learn-able blessings. While the Ursan Blessing is not "special" like the Ursan Aura, the skills from both ARE "special" (one can't learn them themselves, once the effect is lost, the skill is lost). All special skills that are not monster skills are usable by players. This means we can set a 'special' property to those, and ding. We are set. When categorizing, we no longer need a "temporary" parameter. We can just look for special skills that are not monster skills, and that gives us all "temporary" skills. Now, even though a "temporary" parameter is not needed, the infobox could still autocategorize as "Temporary skill" any skill that has the "special" parameter set to anything but "Monster", which will instantly fill the "Temporary skills" category with all the skills that are "special", but not "monster". MithTalk 15:15, 5 April 2012 (UTC)

Type and range categories

While looking at the ranges in skills, I've found two things:

1. For some types people use the type shown in the concise description, in some skills they use the type indicated in the skill, and for some they use the type under which they are listed in the skills and attributes panel. Touches are a good example. They can be listed under skills, under spells, under touch skills, under touch hexes, under hexes, under touch hexes but in the in-game list they are just either "Spell" "Hex" or "Skill".
   • I think we should just types used in the skills and attributes panel there, to make the wiki match better the and add any other modifier some other way. And then set extra types some other way (or have an alternate "Concise type" for those). Some types get a little complicated in the concise description, like: "Half range hex spell" or "Hex Touch Spell".
2. Most skills like those settings, making those categories underused.
   • We could make the type setting autocategorize with default ranges, and then use the range property to override the value. That would give skills a default range. Here are some examples:
     • Spells and most subtypes, signets: Spell range by default.
     • Wards, chants, shouts, glyphs, flash enchantments: Always "no range".
     • Melee attacks and subtypes: Melee range by default.
     • Ranged attacks and subtypes: Projectile range (defined by the weapon equipped and terrain) by default.
     • Skill type: Spell range by default (half range skills have half spell range).
   • And so on.
   • That way one can set all spear attacks to have projectile range, but specifically set spear swipe with melee range. And all spells with spell range, and specifically set touches and half range spells in the range parameter (or use the alternate concise for those).

I think it would be simpler (altough not necessarily easier) to make the work once in the infobox and then edit a bit than manually editing many skills. MithTalk 19:17, 3 April 2012 (UTC)

Yes, please! ^_^ . Concise descriptions have confused folks (I included) into thinking some of those examples are "Official types/terms" used by Anet; which for the average player they may as well be as they are easier to grasp "at-a-glance" then reading the lengthy default description. And requests for updating/expanding the infobox have gone unheeded (Example). --Falconeye 06:22, 21 April 2013 (UTC)

Removing the whitespace

See Help:Ask a wiki question#Template:Skill infobox. --Silver Edge 19:00, 15 September 2012 (UTC)

Attribute categories take precedence over profession categories

When I DPL call the following: category = Warrior skills&Prophecies skills and notcategory = Historical content, I will only get two skills (Flurry and Skull Crack). This is because when attributes are specified in the skill infobox, the <attribute> skills category replaces the <profession> skills category altogether. As such, DPL calls have to be very specific to generate simple lists. The above call should quickly generate all Prophecies Warrior skills (including monster skills and event skills, because they weren't excluded there). Can we also automatically categorize skills correctly with <profession> skills categories, alongside the <attribute> skills categories to avoid this problem? - Infinite - talk 09:49, 17 October 2017 (UTC)

I think I fixed it, but all skill articles need to be cache cleared (null edited) to update properly. Please confirm whether or not this changed anything significant in other ways. - Infinite - talk 10:04, 17 October 2017 (UTC)

AoE by default for shouts?

Initially, I noticed the "Category" bug for two shout skills: "Finish Him!" and "You're All Alone!". Currently both of them are included to the Category:Skills with earshot AoE, even though both are targeted skills with a single target and cannot cause AoE in any way. After some searches, I have found out that a source is in this template:

if not "aoe" and (chant or shout) then "Category:Skills with earshot AoE"

Still, it is possible to prevent such behaviour by adding the line "aoe = none" to the infobox, but this parameter "aoe" is entirely optional, not a requirement! It may be used for skills with AoE when the area size needs to be specified. Why the shouts (like all chants) were declared as AoE skills by default, I cannot comprehend. Shouts can be either untargeted or targeted, and if the "target" parameter already exists in particular infobox, such skill should not be counted as AoE skill, even if "aoe" is omitted. Please fix this bug. --109.252.109.37 11:52, 3 September 2018 (UTC)

Consequences of no "profession" in the infobox

(The story began from this edit, this revert and following discussion about a year ago.)

In the current version of this template the parameter "profession" is additional and optional. This means that if the profession which the skill is tied to is known, then it may be mentioned, otherwise it may be skipped. Indeed, in almost all cases for player-available profession-related skills this parameter exists, the template correctly assigns the profession category, so we can use it in different skill tables and other templates without problems. However, the situation changes dramatically if we look at the common (available to players with any profession) and monster skills.

Current template logic written in the common script (template script is more hard to understand):

if (profession)
     category = profession + " skills";
else category = "Common skills";

As a result, if the infobox of particular skill doesn't have the "profession" parameter, this skill is automatically counted as common. This leads to many problems, first of them can be seen in the article Monster skill. Look at the the profession icon: while near the begin of the article the "monster" icon presents, but near the mid and farther it alternates with "any" icon. This is because the skills at the begin have the parameter profession = Monster, while other skills omit it. Most of them, however, have another parameter special = Monster, as is suggested in the infobox description, or its variations, but unfortunately it isn't taken into account. We can assume that profession icons in this article don't matter much because the subject is about monster skills.

However, this particular approach is wrong in other cases. For example, the article In the Area contains the list of mixed profession-related, common and monster skills. In this article the monster skills have either "monster" or "common" icons, while the player-available common skills have the same "common" icon, which makes them indistinguishable.

Now let's look at the Category:Common skills, which should have only the player-available common skills. In fact, among 551 total skills only about a half are true "Common skills". Another half includes "Monster skills", "Dev content", "Environment skill", "Historical content" and maybe some other smaller subcategories — a real mess.

My suggestion: if the parameter "profession" is omitted in the infobox, the template script should check additional parameters and assign the "Monster" value internally. All possible "special" monster-related cases which present in the Category:Monster_skills should be taken into account.

if (profession == "" && special == ("Monster" || "Spirit monster" || "Passive" || "Teleport monster")) {
    profession = "Monster";
}
// set the categories etc
...

In fact, this may be not as easy, because other templates should also take not the parameter "profession" from the infobox, but the value which should be stored separately or be calculated every time (proficient people may decide whether this really need or not). Eventually the "external" parameter profession = Monster will become excessive and may be harmlessly removed by a batch procedure. Otherwise (if the code remains unchanged) it should be added to all existing monster skills. --109.252.109.37 01:32, 24 December 2018 (UTC)