Template talk:Skill infobox

From Guild Wars 2 Wiki
Jump to: navigation, search

Skill fact smw annotation[edit]


  • Each skill fact is composed of a bunch of parameters.
  • We can't do something like converting a stored plaintext string "A=1;B=2;C=3" into "A=1|B=2|C=3" (using arraymaps) in such a way that it will be correctly read as 3 parameters by a template, so what we can store in smw is limited.
  • Each fact needs to be kept together with the subfacts (parameters fed to {{skill fact}})

Possible solutions

  • A semantic subobject with each of the parameters of skill fact stored separately (shudders)
  • Dump the entire skill fact template - exactly as it is typed into the "variables" parameter in the infobox into the semantic property. This would require us to remove the 3 #set annotations found in {{skill fact}} but is otherwise simple. We could use a variable set in the skill infobox to determine whether to tag skill effects with #set for example.

I think the lack of smw annotation for the skill facts has come up before, probably from Valento. I was exploring skill information popups in my sandbox (User:Chieftain Alex/sandbox) + saw the lack of annotation as something that we're missing. -Chieftain AlexUser Chieftain Alex sig.png 17:55, 1 February 2015 (UTC)

It will probably turn out that some of the sub-templates of {{skill fact}} produce their own #set annotations too, but I haven't found any that do yet... -Chieftain AlexUser Chieftain Alex sig.png 17:57, 1 February 2015 (UTC)
Maybe I mentioned facts. I don't know how SMW handles these things internally though. If space is limited, why don't you split? May look squishy, but here you go:
Has skill fact damage: "strikes=5,value=500;value=500,alt=Damage under burning" (accounts for two damage skill facts)
Has skill fact misc: "alt=Where is ish?,value=1700,image=Chicken.png" (accounts for one miscellaneous skill fact)
...and so on. – Valento msg 19:03, 1 February 2015 (UTC)
Oh, you mentioned that. lol – Valento msg 19:06, 1 February 2015 (UTC)
Yep your page was the one that I read yesterday or whenever it was.
(Edit conflict) While splitting the fact into comma separated chunks works fine for javascript (or any other markup except wikitext), per the second bullet point I made above, I can't convert that back into template form - at least without a bunch of string functions + a complete rewrite of the way that a query oriented {{skill facts}} generates the output. It could be done I guess. I'll have another go -Chieftain AlexUser Chieftain Alex sig.png 19:09, 1 February 2015 (UTC)
I'm open to suggestions on the separator that we store the parameters of the skill facts with, but I've got a working setup on User:Chieftain Alex/sandbox3. -Chieftain AlexUser Chieftain Alex sig.png 20:15, 1 February 2015 (UTC)
Looking at the skill facts property, is there a reason why we have to store this super awkward format? We probably can’t use any of that information to filter (e.g. “get all skills that apply confusion”), so having it like that is not really useful, right? Couldn’t we just store the result text (i.e. pretty wiki markup) instead then? poke | talk 07:44, 2 February 2015 (UTC)
So wrap the entire skill facts template output in the property? good. -Chieftain AlexUser Chieftain Alex sig.png 07:54, 2 February 2015 (UTC)
Didn't realise last night when I tried that that it didn't work only because of the triple colon (smw markup + indent).
Even better, storing it as markup has removed the #set functions so we don't even need to rewrite the set logic to only trigger inside infoboxes. -Chieftain AlexUser Chieftain Alex sig.png 08:10, 2 February 2015 (UTC)
Any properties defined in skill fact were temporary, the whole skill fact was suppose to be in a subobject from the start. Alex wiped the information on Guild Wars 2 Wiki:Semantic MediaWiki/Skills (The correct page for this discussion) without any discussion. The point was to hopefully do stuff like "get all skills that apply confusion". If we aren't doing that, then yeah, all the property will be is pretty wiki markup.--Relyk ~ talk < 08:36, 2 February 2015 (UTC)
As I've pointed out before, only the first 40 characters of a text property can be searched against (unless the total length is < 72). So neither of these formats is useful for searching. —Dr Ishmael User Dr ishmael Diablo the chicken.png 13:12, 2 February 2015 (UTC)
@poke, since each skill fact starts with a colon ":" - one of the symbols that SMW doesn't like, I've wrapped all of the code inside {{skill fact}} apart from the colon with the property.
This mostly works. However, when multiple skill facts are on one page + queried for, smw splits it by commas. So to untangle 4 facts I would replace the three separating commmas with a <br> or something. This doesn't work properly if the numerical values contain commas... ideas? -Chieftain AlexUser Chieftain Alex sig.png 18:47, 2 February 2015 (UTC)
Replace them with "-" characters like with files? I remember I use ~ for line breaks in storing text on the achievement subobjects.--Relyk ~ talk < 21:29, 2 February 2015 (UTC)
Do you mean
{{#set:Has skill facts={{#replace:{{{variables}}}|:|~}}}}
because I think that might also remove the colons between each skill fact text + numeric :/ -Chieftain AlexUser Chieftain Alex sig.png 21:35, 2 February 2015 (UTC)
You don't need the colon in the property value anyways. Probably replace all the commas in the value with semicolons. It should look the same as achievement tiers as the only way to keep the skill fact order is to store it in a single format string. If we have subobjects, we can have a internal property for ordering them.--Relyk ~ talk < 22:45, 2 February 2015 (UTC)

(Reset indent) Pseudo-code for using subobjects and for using a format string. Storing a format string of a skill effect violates the idea of being semantic in any sense, but if we want it that way. If we use subobjects, that's a query for each skill, similar to the recipe subobjects. We can probably do fun stuff like damage calculations on skills in forms that way. Combo finishers and break stun still need entries as skill facts for output. I'm not sure it makes sense to still associate those values with the skill page as that makes queries weird.

A format string would only be useful for viewing the skill facts obviously. Valento would need the subobjects or parse the wiki code himself for the skill facts.--Relyk ~ talk < 19:23, 3 February 2015 (UTC)

Actually if anyone tries to use mediawiki as some sort of "database" or data source, they would prefer it to be semantic. At least for me, grabbing template text to parse skill facts is actually more structured than using ask api since it wouldn't improve much if we keep on insisting on wikitext in the end. – Valento msg 19:38, 3 February 2015 (UTC)
Btw. if you end up finding a solution, please take into account that skill facts don’t necessarily follow the format known to the skill facts template. When I was documenting Caithe’s skills, I had many difficulties matching the in-game format for those skills and often had to opt for standard wiki text instead. poke | talk 20:09, 3 February 2015 (UTC)
Hmm... if you're referring to skills facts without icons, that could be easily achieved by tweaking misc skill fact, adding a wildcard for image parameter (eg. noicon) or another parameter to omit icon display. – Valento msg 20:14, 3 February 2015 (UTC)
Btw, skill facts aren't verbatim in the wiki. Ishmael explained that to me long ago. We don't document for example "Poison(5s): XXX damage, -YYY% healing effectiveness", we only let value parameter be "5" and it will display "Poison: 5s" (this is intentional). – Valento msg 20:30, 3 February 2015 (UTC)

(Reset indent) Sorry that it took me so long to get around to thinking of a working solution Valento. It turns out just wrapping the infobox "variables" parameter with a #set is sufficient for us. Whether or not we do eventually go for some kind of subobject route this should work for our purposes for the moment. -Chieftain AlexUser Chieftain Alex sig.png 20:39, 3 February 2015 (UTC)

Nope. It's not something much needed tbh, migrating from pulling raw page's wikitext to smw api was just a thought I had inspired by Ishmael's good job with SMW usage here. I know it's not very easy to come up with a solution, I'm sorry I'm unable to help you guys more. – Valento msg 21:23, 3 February 2015 (UTC)

Proposal: Underwater availability[edit]

I'd like to propose a change that will make underwater availability (hopefully) more semantic. It's really simple: instead of "uw-replaced-by" e "uw-replaces", change to "uw-available" (y/n) and "uw-replacement". Replacement is semantically and technically logical depending on context. It goes like this:

if (uw-available=='y'){ // eg. Whirpool is usable underwater
    // set availability property to yes/true right now
    if (uw-replacement){ // eg. Whirpool replaces Tornado
        // this replacement will replace (no pun intended) "uw-replaces"
}else{ // eg. Tornado isn't usable underwater
    if (uw-replacement){ // eg. Tornado is replaced by Whirpool
        // this replacement will replace (no pun intended!! I swear) "uw-replaced-by"

Just rename them and change logic. Omiting "uw-available" set it automatically to false. Don't worry about skills usable underwater, I can add that information to all skills (or at least profession ones). (PS.: don't mess with my code indenting!) – Valento msg 13:55, 16 February 2015 (UTC)

A better method would be to a "mode" parameter identifying whether it can be used on land or water, defaulting to both. The "replacement" parameter would identify the replacement skill if it exists.--Relyk ~ talk < 15:29, 16 February 2015 (UTC)
That would result in the same behavior, except for parameter value which would be "land/uw", but I think of underwater mode more of an additional mode, not a major one (hence no major adjustments made since launch). Whichever works I'm good with, I'm just worried about availability information. Right now, you just can't retrieve whether a skill can be used under water or not (Ishmael mentioned this on a recent discussion). – Valento msg 16:10, 16 February 2015 (UTC)
Recent? If you consider 2.5 years ago "recent", sure. And yes, you can retrieve that information from Property:Is usable underwater, which is only relevant to healing/utility/elite skills; I've updated the template to set a default value of "true" for everything that doesn't have the uw-replaced-by parameter. (For weapon skills, it's directly derived from the weapon type, so it doesn't need anything more than that.) There are no skills that are only usable underwater without a terrestrial replacement, so this should cover everything. —Dr Ishmael User Dr ishmael Diablo the chicken.png 16:26, 16 February 2015 (UTC)
*Thumbs up!* Btw, I didn't mean that discussion. – Valento msg 16:46, 16 February 2015 (UTC)
Can 6-0 slots for activity skills be used underwater? – Valento msg 18:35, 16 February 2015 (UTC)
Example: Consume Ration. – Valento msg 18:36, 16 February 2015 (UTC)
Southsun Survival is the only one where underwater areas are accessible, so you'd have to go test it. All the other rotation activities have a small, restricted playing area, so it's untestable. Costume Brawl/Belcher's Bluff items can't be used underwater. —Dr Ishmael User Dr ishmael Diablo the chicken.png 19:32, 16 February 2015 (UTC)
User talk:Dr ishmael#SMW - discussion you were referring to occurred last week.. -Chieftain AlexUser Chieftain Alex sig.png 00:20, 17 February 2015 (UTC)
Aha. I believe he misunderstood what I was saying there - when I said "you can't ... filter for skills that are usable [underwater]" I meant in the context of running a semantic query specifically to return that set of skills. I didn't mean that there was no way of finding that information at all. And now that I made the template set a default for that property, we can run that query. —Dr Ishmael User Dr ishmael Diablo the chicken.png 03:20, 17 February 2015 (UTC)
How can you tell if Detonate Elixir B, or Detonate Flame Turret are usable or not underwater? – Valento msg 02:41, 28 February 2015 (UTC)
Is it possible to move {{#if:{{{uw-replaced-by|}}}|{{#set:Is usable underwater=N}}|{{#set:Is usable underwater=Y}}}} down the code, so it catches ALL skill types/variations, having it default to true? If you want to enforce it's not usable underwater, you could fill that parameter with uw-replaced-by = none. As of now, I have no means of knowing whether it's usable underwater or not, it's a simple case that defaulting to YES should be broader. – Valento msg 02:47, 28 February 2015 (UTC)
Of course, I could assume "absence of value" as true in my code, but I had this talk with Ish some time ago and it's not a nice pattern to follow. – Valento msg 02:50, 28 February 2015 (UTC)
Detonate Elixir B and Detonate Flame Turret need to set their slot to utility instead of omitting it.--Relyk ~ talk < 04:51, 28 February 2015 (UTC)
No. They're slotted in mechanics bar. Technically they are not utilities, despite being dependant on those. – Valento msg 04:55, 28 February 2015 (UTC)
It appears to me that we don't currently have a parameter to indicate that a particular skill can only be used underwater. Is that correct? In which case I would propose {{{uw-only|}}}. -Chieftain AlexUser Chieftain Alex sig.png 10:46, 28 February 2015 (UTC)
(Reset ident) That's why I proposed that design up there, so we could catch underwater values for EVERY skill. Right now I have a manual filter (not beautiful, btw):
if (!_data["underwater"]&&!_data["weapon"]&&!_data["wslot"]&&_data["context"]!="Profession mechanic"&&_data["name"].indexOf("Detonate Elixir")==-1){
    $tooltip.find('.header.tbl .col.top.right .props').append('<li><span class="icon not-available-uw"></span></li>');
It could be adapted to template so it could skip these cases. – Valento msg 11:38, 28 February 2015 (UTC)
Ah. You could default to false for all other cases (i.e. not on 6-0 skillbar range). – Valento msg 11:41, 28 February 2015 (UTC)
Argh, forget everything I said. I understand now (I guess). I was logically comparing in my script, I should be comparing to false specifically. I see how setting this property to false would lead to semantically incorrect data. – Valento msg 11:55, 28 February 2015 (UTC)

Multiple weapon slots[edit]

Refer this page. Further discussion can be added here. – Valento msg 13:59, 16 February 2015 (UTC)

I would create three separate skill pages for each slot, no support needed.--Relyk ~ talk < 15:24, 16 February 2015 (UTC)


  • New skill types for each legend
  • Skill type identifies the set of skills associated with a legend.
  • Weapon skills stay the same
  • Need skill fact for resistance
  • Does Embrace the Darkness need to describe the toggle? We have the activation type option.

--Relyk ~ talk < 22:14, 20 February 2015 (UTC)

Skill and Related Traits[edit]

Can we have a new parameter for documenting related traits of a skill? So when an user visit a skill page, one can view a complete and nicely formatted list of traits affecting the skill. Currently wiki contributors have to manually format a Related Traits section for every skills. Some entries, however, lack a profession icon, some lack a trait icon, and some lack a particular trait. A proper template can improve this and save time for wiki contributors.

Trait pages may make use of a similar parameter too but I think it is not good for weapon-related traits which affect at least 5 skills. Fanolian (talk) 11:21, 24 February 2015 (UTC)

Maybe some sort of lookup. For a single skill have linked-traits parameter which takes numerals, or some more specific format, all comma-separated. Something like X,IV,minor-adept,minor-grandmaster, or major:X,major:IV,minor:adept,minor:grandmaster. It should be easy to #ask for given parameters. – Valento msg 11:38, 24 February 2015 (UTC)
Actually no. This will require unnecessarily heavy #ask usage + processing. Simply having that parameter containing the names would be enough (unless there is a smaller identifier, but AFAIK there's no "id" for traits). And... – Valento msg 13:10, 24 February 2015 (UTC)
Actually the first input format would be "traitline:number or :tier", if #ask was used. Like Water Magic:1,2,7,adept;Fire Magic:grandmaster, meaning "major traits 1, 2, and 7, and minor trait adept from Water Magic, and minor trait grandmaster from Fire Magic". I'm actually getting confused in my own confusion. – Valento msg 13:40, 24 February 2015 (UTC)
On the formatting, the profession icon is completely unnecessary because it's already in the infobox - you'll never have traits from a different profession than the skill, so it's pointless to include the icon again. It's also better to format the trait lines as definition lists (using ; and :) instead of as headers with unordered lists (== and *), because that way you avoid generating a table of contents on these (usually) very short pages. I don't know who did it or when it happened, but someone started making skill pages look like the format you're using, and now everyone's copying it all over the place. It really needs to be changed back to the simpler format - I should be able to get on that soon.
@Valento: you're thinking about this wrong, primarily because your method won't update automatically whenever traits change. IF we do something like this, we would make annotations on the trait pages about which skills they affect (not sure of the best way to do that, whether to denote all skills individually or denote skill/weapon types). On the skill page we would simply query for which traits affect the skill (or its type). —Dr Ishmael User Dr ishmael Diablo the chicken.png 13:51, 24 February 2015 (UTC)
Ah. That way you could query by their ids! I feel stupid. – Valento msg 13:53, 24 February 2015 (UTC)
Uh.... no. You would query something like [[Affects skill::{{PAGENAME}}]]. If you're querying by ID, then you're doing something wrong. —Dr Ishmael User Dr ishmael Diablo the chicken.png 13:57, 24 February 2015 (UTC)
How would you create this relationship? By pagename? For example, a single trait affecting 10 skills. Would it be a list of pages? – Valento msg 14:01, 24 February 2015 (UTC)
"(not sure of the best way to do that, whether to denote all skills individually or denote skill/weapon types)"Dr Ishmael User Dr ishmael Diablo the chicken.png 18:16, 24 February 2015 (UTC)
I'm getting a better idea of what would be useful here. We should have two properties, trigger (what "procs" the trait or what it applies to) and effect, which would be set by the trait infobox through a couple new parameters.
We'd have to compile a list of all the different triggers and effects we need to link up, of course, but I think this could work well. —Dr Ishmael User Dr ishmael Diablo the chicken.png 18:41, 24 February 2015 (UTC)
Wish I could commit to that, but I can't. Next week would be a good idea, though! :D – Valento msg 18:56, 24 February 2015 (UTC)
Commit, what? We're just discussing a preliminary design right now. o_O —Dr Ishmael User Dr ishmael Diablo the chicken.png 21:07, 24 February 2015 (UTC)


I have not enough experience with templates to make the change. Could it be possible to make this infobox accept tonics in the twohand parameter when the activity is set to Costume brawl so the infobox links to to the tonic too? MithUser MithranArkanere Star.pngTalk 17:25, 1 March 2015 (UTC)

The closet thing I managed is using Slot = toy then Toy = "Tonic name". I'll try to copy that to make a slot = Tonic Tonic = "Tonic name= MithUser MithranArkanere Star.pngTalk 17:28, 1 March 2015 (UTC)
Well, adding the tonic entry was an easy copypaste. But now the Tonic parameter needs to accept multiple entries like the bundle does. And I don't know how to do that yet. MithUser MithranArkanere Star.pngTalk 17:47, 1 March 2015 (UTC)
The skills come from the transform effect, not the tonic itself. But most effects are hidden, so we would have to use the tonic name anyways. I feel like having bundle/tonic as values in the slot parameter doesn't make sense for the infobox, we might want to go with a different word like auxillary or source.--Relyk ~ talk < 20:01, 1 March 2015 (UTC)
Often we don't know the name of the form or bundle, so we are often limited to the name of the consumable that provides it. I think that ideally, for temporary skills we'd just have a "source" parameter, and and the infobox would list each source in the infobox in its row. Putting all bundles under Bundle, all consumables under Consumable, all Objects under object, all toys under Toy, all tonics under Tonic, etc, then have a default "Source" row for whatever else may not be detected by the infobox. In any case, My only request is being able to put all sources of the skill regardless of type of source. For now you can do that with Bundles, listing all skills, objects and consumables that provide it, although the name of the entry in the page is always "Bundle" for bundles even if the known source is a consumable instead a bundle object. MithUser MithranArkanere Star.pngTalk 22:59, 1 March 2015 (UTC)
We don't need a specific parameter for the type, I imagine we can query the page for the object/item/effect type. If the source is unknown, the parameter can simply be the source type. Toys aren't related as they have their own equipment slot; I only refer to sources that don't have an equipment slot.--Relyk ~ talk < 01:19, 2 March 2015 (UTC)
Yup. That's what I was saying. You would just put a list of whatever provides the skill in a "source" paramenter, and the infobox searches for each entry, looks what each one is, and shows each one under the appropriate row like "Bundle", "Consumable", "Toy" or "Tonic" for people to click.
Oh. And toys no longer have their own equipment slot. They are are now gizmos that give a fragile bundle when used. The only thing that really makes them "toys" is that the bundles some of them give have the same skills the original toys used to give. Now they aren't really different than a kite, an instrument or any other gizmo or consumable that provides a bundle. Well, unless you wanted to keep the term "Toy" for the now gone equippable toys. But I think it's a good idea since they are now historical .MithUser MithranArkanere Star.pngTalk 02:02, 2 March 2015 (UTC)
Ah right, we don't want to keep the toy term since it's been phased out. We only identify the gizmo and the bundle it gives.--Relyk ~ talk < 03:35, 2 March 2015 (UTC)
Wait. You mean just in the infobox, right? Even though the type of item is gizmo now, the game still refers to them as 'toy' as in "Type of gizmo that gives costume brawl skills". I'd rather keep the Toy page and the toy category because of that. In any case what I still want is being able to put all the sources of a skill on the skill. If, for example, a skill is obtained with both a tonic (which is a consumable) and a everlasting tonic (which is a gizmo), I should be able to put both in a parameter. And there's cases of consumables that give bundles that have the same skills as player bundles, like the one that gives the same exact skills as a Flamethrower kit. MithUser MithranArkanere Star.pngTalk 14:37, 2 March 2015 (UTC)

replacing 'skill-point' with 'hero point'[edit]

I'm about to run AWB to remove the now-deprecated skill-point parameter from all instances of this infobox. When that's done, I'll modify the template to switch this over to hero points so we can start documenting the new training costs. —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:04, 24 June 2015 (UTC)

Alright, skill-point is eradicated. Time to make the switch. —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:46, 24 June 2015 (UTC)
And removing the associated tier parameter as well... —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:54, 24 June 2015 (UTC)

Empty animation container visible when background is dark[edit]

When the skill name is short enough this is not really noticeable (light element on light background). But when skills names are long enough the animation container (empty paragraph) is noticeable (light element on dark background). This animation container was added in r147274, and the style (div.infobox .icon p) was added in r147273 and expanded upon in r254156.
Because animation images aren't commonplace, I think that the paragraph tag in the current code
...</div><p>{{ifimage|{{PAGENAME}} animation.gif| [[:File:{{PAGENAME}} animation.gif|Animation]] }}</p></div>...
should only be created when the image exist, like so:
...</div>{{ifimage|{{PAGENAME}} animation.gif| <p>[[:File:{{PAGENAME}} animation.gif|Animation]]</p> }}</div>...
Thoughts? --BryghtShadow (talk) 14:10, 29 June 2015 (UTC)
My suggestion was implemented while I was writing this. --BryghtShadow (talk) 14:14, 29 June 2015 (UTC)
Bad luck, I spotted it when i was having a look at your edit to Detonate Supply Crate Turrets :) -Chieftain AlexUser Chieftain Alex sig.png 14:28, 29 June 2015 (UTC)

Related traits: Second pass[edit]

So, we've discussed "Related Traits" early this year. Quite a few ideas rolled out but nothing conclusive, so I thought about another thing! How about we follow the same idea of "skill facts"? So we'd have a {{Related trait}} template, and it would look like this:

  • relatedtraits - Displays a "Related Traits" section right below infobox with all traits related to this skill.
{{Skill infobox
| // ... stuff
| relatedtraits = {{related trait|Fire|Pyromancer's Puissance|Pyromancer's Training|...}}

Not sure how feasible this is, also I don't know if wiki supports a varying amount of parameters for a single template. The documentation for {{Related trait}} would be something like:

  • param1 - Specialization the traits belong to.
  • param2...paramN - Traits.

I am convinced that dumping skill info into trait infobox (i.e. which skills each trait affects) is not the way to go because I feel skills are much more "dependant" relationship-wise to the traits than the other way around. Either way, what do you guys think? – Valento msg 11:39, 4 July 2015 (UTC)

There we go. I've adjusted my skill infobox template, and used a related trait template. Ideas? – Valento msg 12:31, 4 July 2015 (UTC)
This example showed I need to get rid of disambiguation parentheses, but I have no idea how I do that. Also, I think "related trait" incorrect, it should be "related spec", because it's a list of traits... maybe just change to plural... I don't know, I'm confused. *Valento hurts himself in his confusion!* – Valento msg 12:37, 4 July 2015 (UTC)
That's a nice template, but it still doesn't alleviate the need to update individual skill pages whenever a trait changes, which I had already brought up in the earlier discussion.
"skills are much more "dependant" relationship-wise to the traits than the other way around" Exactly, and that's why we need to annotate the trait pages with what they affect, so that the skill pages (and pages for boons, conditions, etc.) can query that information. —Dr Ishmael User Dr ishmael Diablo the chicken.png 16:06, 4 July 2015 (UTC)
Yeah, got it backwards (maybe it's because it's a damn cold day). I really wanted to have this information automatically displayed, but this time it would involve SMW, and I'm not really confident about touching this thing... – Valento msg 17:05, 4 July 2015 (UTC)

A couple anomolies[edit]

A couple things I noticed while browsing. Using https://wiki.guildwars2.com/wiki/Strike as an example.

1: The Activ. type link links to https://wiki.guildwars2.com/wiki/Skill#Skill_types. This is the correct page but the wrong section. I think it should be https://wiki.guildwars2.com/wiki/Skill#Activation_type instead.

2: The Sequence section text for the infobox is itself a link to https://wiki.guildwars2.com/wiki/Sequence_skill . This link doesn't really need to be here and is a little confusing on chain skills.

3: Do we need an activ-type variable for sequence skills? Especially if we remove the sequence_skill link.

Chrury (talk) 18:57, 10 July 2016 (UTC)

Chain skills are a type of sequence skill. We could be smart and derive the activation type if you specify a sequence, but it's better to be explicit.--Relyk ~ talk < 21:46, 10 July 2016 (UTC)

Monster skills revisited[edit]

For original thread: Template talk:Skill infobox/Archive 4#Monster_skills.21

Well, I don't want to necro this post, but it appears that ArenaNet has begun developing hoverable skills with all the info on it within the combat log (yay! more work). They can be found on Wing 4 bosses (Bastion of the Penitent). Could someone please update the infobox to make room for skill sources of monsters? Sythe 02:54, 17 February 2017 (UTC)

Edit: Well, it turns out that there does appear to be a monster parameter for the infobox. Unfortunately, profession is still set to default when setting a monster. Not sure if someone can fix that... Sythe 16:07, 19 February 2017 (UTC)
There are still some things that probably need to be fixed for monster skills, see the example Annihilate from Deimos:
  1. Is for profession: Do we want to set this property?
  2. Is for race: Do we want to set this property?
  3. Default skill icon: Since we probably will not get any monster skill icons, do we want to set a different default icon for monster skills?
Nefastu 20:10, 27 May 2017 (UTC)

API link[edit]

Apparently the template does not try to set an API link when the profession is set to "common" or not set (default to common). The api link is included correctly when choosing the parameter "any". Racial skills are however whitelisted in the API as for example Rending Swipe. --Soulblydd (talk) 21:56, 14 March 2017 (UTC)

I think environmental weapon skills get listed as common, but aren't listed in the API for reasons. Something to look in to if you make a fix. 22:09, 14 March 2017 (UTC) The preceding unsigned comment was added by SarielV (talkcontribs).
Slight sidetrack, why do we have an API link in the infobox? I didn't know this is something readers commonly look at or would find useful.--Relyk ~ talk < 00:27, 15 March 2017 (UTC)
It was to simplify getting the power coefficients out + to help spot the update changes. -Chieftain AlexUser Chieftain Alex sig.png 10:31, 18 March 2017 (UTC)
Since the removal of the API link in the infobox, trait skills have been added/whitelisted on the API. Maybe the link to the API can be added again, as long as the parameter profession or race is set? —Nefastu 15:51, 27 May 2017 (UTC)
I would still support a link to the API, I'm wondering what skills we've got documented that don't have a profession/race. Are they stolen skills? (edit: oh right, bundle/environmental weapon skills) -Chieftain AlexUser Chieftain Alex sig.png 17:22, 27 May 2017 (UTC)
{{#if: {{{id|}}} | {{#if: {{{race|}}}{{{profession|}}} | {{#if: {{{status|}}} | <!-- do nothing if non-current --> | 
;External links
:[https://api.guildwars2.com/v2/skills?ids={{#replace:{{{id}}}| |}} API]
}} }} }}
something like that then? -Chieftain AlexUser Chieftain Alex sig.png 17:28, 27 May 2017 (UTC)
Stolen skills and bundles are whitelisted, except for Forage bundles, for example Bone Crack (Bone). However, that skill does not set the profession or race parameter, so these skills don't get an API link to start with. So yes, that snippet looks fine to me. —Nefastu 19:35, 27 May 2017 (UTC)


Going to have to add a 4th chain to the infobox chain4 = , soulbeast already has 4 skills in their #1. —Ventriloquist 11:32, 2 August 2017 (UTC)

Another request! We now have mounts, with skills, so it'd be nice to have another parameter (similar to bundle), I'm thinking mount = ? —Ventriloquist 23:17, 3 August 2017 (UTC)
chain4 added but I haven't done anything about mounts yet. I'll have to watch one of these spoiler beta videos to see how it works (like gliding, so no parent skill + we can't just use a layout like Kick (Rampage)? - maybe check for context on "parent" parameter but use that + change label). -Chieftain AlexUser Chieftain Alex sig.png 06:18, 4 August 2017 (UTC)
Kind of. Here's a snippet of the mount UI - only one (attack) skill is available for each mount, but it's neither situated in the regular 1-5 hotbar, nor is it a special action skill. There's also a dismount skill, I'm assuming, which is placed at the same position where the mount skill is as well (could treat this as Return?). So basically, it wouldn't work with parent, imo. —Ventriloquist 09:08, 4 August 2017 (UTC)

Ammo Information[edit]

With the new Ammo Mechanic we will likely need to add ammo information. How do we want to display that The preceding unsigned comment was added by Anzenketh (talkcontribs).

Is the clear div necessary?[edit]

There's a clear template (both) used right before the closing includeonly tag in the template source. That adds a lot of empty space to the skill pages. Is there a valid reason not to remove it? Update: Forgot to sign... Here it is :) — Blackice (talk) 19:06, 9 November 2017 (UTC)

Marginally unrelated, but could you stop editing templates in the short-term? the job queue is way too long and everything is laggy on the wiki at the moment. (primarily due to the upgrade, but adding more stuff now, e.g. infoboxes or vendor icons, will mean it will stay slow over the weekend) -Chieftain AlexUser Chieftain Alex sig.png 19:36, 9 November 2017 (UTC)
Sure :( — Blackice (talk) 21:25, 9 November 2017 (UTC)