Template talk:Skill infobox

Archive

---

• 2010
• 2011
• 2012
• 2013-2014

Skill fact smw annotation

Problems

• 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 Alex 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 Alex 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 Alex 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 Alex 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 Alex 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 Alex 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 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 Alex 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 Alex 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 Alex 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

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 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 19:32, 16 February 2015 (UTC)

User talk:Dr ishmael#SMW - discussion you were referring to occurred last week.. -Chieftain Alex 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 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 Alex 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

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)

Revenant

• 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

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 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 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 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.

• Illusion of Vulnerability would have [[Trait applies to::Interrupt]][[Has trait effect::Applies vulnerability]].
  • Interrupt#Traits_that_trigger_on_interrupt would query for [[Trait applies to::Interrupt]].
  • Vulnerability#Traits_that_apply_vulnerability would query for [[Has trait effect::Applies vulnerability]].
• Mental Torment would have [[Trait applies to::Mind Wrack]][[Has trait effect::Damage]].
  • Mind Wrack would query for [[Trait applies to::Mind Wrack]].
  • Damage doesn't list related traits currently.

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 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 21:07, 24 February 2015 (UTC)

Tonics

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? MithTalk 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= MithTalk 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. MithTalk 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. MithTalk 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 .MithTalk 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. MithTalk 14:37, 2 March 2015 (UTC)

replacing 'skill-point' with 'hero point'

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 00:04, 24 June 2015 (UTC)

Alright, skill-point is eradicated. Time to make the switch. —Dr Ishmael 00:46, 24 June 2015 (UTC)

And removing the associated tier parameter as well... —Dr Ishmael 00:54, 24 June 2015 (UTC)

Empty animation container visible when background is dark

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 Alex 14:28, 29 June 2015 (UTC)

Related traits: Second pass

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 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

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

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

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. 184.18.209.226 22:09, 14 March 2017 (UTC) —The preceding unsigned comment was added by SarielV (talk • contribs).

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 Alex 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 Alex 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 Alex 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)

chain4

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 Alex 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

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 (talk • contribs).

Is the clear div necessary?

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 Alex 19:36, 9 November 2017 (UTC)

Sure :( — Blackice (talk) 21:25, 9 November 2017 (UTC)

Skill properties wishlist

We are lacking some properties to fully sort skills, especially slot skills; weapon skills are in a pretty good spot, see {{weapon skill table}} (which is only lacking a proper weapon sort). I will list the properties on my wishlist (bold ones) together with the already implemented properties (linked ones) in my intended sort property chain:

1. Property:Has profession sort order
2. Property:Has specialization sort order
3. Property:Has skill context sort order (new) — to sort e.g. Healing < Utility < Elite.
4. Property:Has skill type sort order (new) — to sort by skill type (currently not all skills have a skill type); the sort skill type will be i) the skill type itself or ii) inherited by chain1 skill or iii) Skill without type as default value.
5. Property:Has weapon type sort order (new) — to sort by weapon (equivalent to skill type sort order for slot skills), similarly to Property:Has weapon type number set in the item infobox, but bundles and transform skill might receive a number too, also this one had a default value.
6. Property:Has attunement sort order
7. Property:Has skill slot number — currently weapons only
8. Property:Has skill sort order (new) — to sort and group skills, e.g. sorting slot skills or Dual Wield skills that have the same slot number but a clear order that isn't preserved by the chain position. If parameter is set, then the parameter is used, else if it is a chain skill then the sort order is set to chain1, else to it's page name.
9. Property:Has chain sequence position

This would allow us to sort and create almost all straight forward skill tables automatically as they are done by hand right now (of course some difficult engineer tool belt or profession mechanic skill tables still needs to be done by hand). --Tolkyria (talk) 20:32, 1 February 2020 (UTC)

Added links, marked them as "(new)". --Tolkyria (talk) 16:04, 13 February 2020 (UTC)

Possible cosmetic improvement to the "recharge" parameters?

I was looking at "Stand Your Ground!", and noticed that the PvE and WvW variants had the same recharge, but the latter still had to be specified, because the sPvP variant had a higher one. As such, the recharge gets highlighted as if there was a difference when switching between PvE and WvW.
Could there be "a check" in the template to ignore the highlight, if values that are necessary to specify between versions are identical? Or is there already a function for this in place?
I assume recharge parameters have code from the days when a PvP split meant a version of a skill meant both WvW and sPvP? - J.P. 02:07, 17 April 2020 (UTC)

Probably possible by modifying Template:Infobox statistic split. -Chieftain Alex 06:07, 17 April 2020 (UTC)

Remove "-" from parameter names

The parameter names are a mess. Some of them use "-" to separate words and some don't. I propose removing the "-" from the parameters so it is consistent. --BuffsEverywhere (talk) 02:55, 27 October 2021 (UTC)

Add backwards compatibility to the template + raise a gw2w:bots request. It's probably something I can look at tomorrow on my next day off. -Chieftain Alex 06:18, 27 October 2021 (UTC)

Backwards compatibility added + request submitted. -Chieftain Alex 10:16, 28 October 2021 (UTC)

Please keep the full backwards compatibility in Skill infobox/historical such that we have a chance to view old versions of skill pages without renaming all parameters by hand, namely by editing and simply adding the template suffix /historical. --Tolkyria (talk) 10:42, 28 October 2021 (UTC)

In-game description

What's this half-assed edit about removing the "In-game description" suffix?

Literally every infobox uses this line to indicate that the wiki is quoting the tooltip directly (that's how it can be found in-game). So with such a partial edit we create only inconsistencies, for example similar infoboxes like trait infobox or effect infobox are still using it. More general, what's the difference between random tooltip, e.g. item tooltip using item infobox (or any subvariant of this), which still displays the line "In-game description" and a skill tooltip using skill infobox which now doesn't display it.

Also what's the exact reason to not use it? The edit summary gives no hint at all, it only says "per suggestion from JP on discord (which I wholeheartedly agree with) - removing line "In-game description" from below facts in the skill infobox."

My reasons to keep the line "In-game description" are:

1. Clear indication that we quote from an in-game tooltip.
2. Consistency between the wiki infoboxes as well as continuously keeping a well-established format over all these years.

--Tolkyria (talk) 08:58, 31 January 2022 (UTC)

For context, the discussion on Discord was about the Count Recharge inconsistency on On My Mark. The ingame description/tooltip lists the wrong recharge (30s) but the actual recharge is 25s. Removing the "In-game description" would let us show the actual value in the skill fact when there is an error like this. Nonetheless, I don't agree with the blanket removal of the line; we could simply use a parameter to disable it on a case-by-case basis. --BuffsEverywhere (talk) 09:49, 31 January 2022 (UTC)

So given your explanation, this means that it was not only just a purely cosmetical edit (by getting rid of these line) but also a structural edit shaking up how we document the wiki, implicitly stating that we are no longer bound to correctly document the in-game tooltip but can freely extend or remove anything from the infobox tooltip "quotation". If this is true than note that this edit was performed without a single wiki talk page discussion.

In my opinion we should keep the currently used method (the method the wiki used for nine plus years until this edit) of being strict and exactly mirror the in-game tooltip, otherwise the definition of what to document would get very shallow, in the end causing more confusion to the wiki users than clarifying it. Furthermore, we have several very visible tools to deal with incorrect tooltips, for example the templates bug, anomaly or sic or simply using the notes section, that allows to clearly explain potential mistakes. Right now, I don't think there's any reason to weaken or get rid of our "mirror tooltip"-documentation method.

May I suggest to take a look at List of bugs#Skills and traits and use your browser search to search for "tooltip" to see how we have successfully dealt with them until now.

--Tolkyria (talk) 10:35, 31 January 2022 (UTC)

For a wiki documenting the game, most of the quoted content is verbatim, be it dialogue or infoboxes or whatever. Having this pointless line under every single infobox, not to mention in the mobile popups too, actually is completely redundant and utterly pointless.

I actually want to replicate this change on all infoboxes using "in game description". It adds nothing. As a starter for ten, I edited one infobox to observe the feedback. -Chieftain Alex 17:38, 31 January 2022 (UTC)

"It add nothing." Formatting-wise it adds a lot, this paragraph introduces a nice margin, now the vertical bar directly ends with the last entry, no padding/margin at all. Wiki-popup-wise it acts as a separator between the quoted in-game tooltip and the wiki intro text, which might not be often used on skill pages but in fact is used on other pages (e.g. items). Content-wise it seems to be a matter of taste, for me it's fine to quote the (obivious) source, additional well-formatted explainations, even if they might feel redundant, never hurt. --Tolkyria (talk) 19:09, 31 January 2022 (UTC)

My issue with mirroring the tooltip is the value set by the skill fact affects SMW properties which may be used by other templates. For example, it is misleading for Vigorous Shouts to say it reduces On My Mark to 24s. --BuffsEverywhere (talk) 11:29, 1 February 2022 (UTC)

The amount of wrong skill facts that are shown (incorrectly) in a smw query is incredible small, first by wiki template design we mostly show the skill names only (e.g. template skill list on boon/condition pages) and second the in-game tooltips are in general showing the correct values. Here, you could try to disable it and add the correct facts silently; something like the following might work, though I guess we shouldn't use such hacks too often (or add an official smw disabling parameter to skill fact, however it needs to somehow justify the usage: 15000+ correct skill facts compared to a few wrong skill facts).

| facts =
...
<!-- disable smw subobject creation --> {{#vardefine:enable facts|false}}{{skill fact|Count Recharge|30}}{{#vardefine:enable facts|true}}
...
| hidden facts = {{skill fact|Count Recharge|25}}

--Tolkyria (talk) 14:21, 1 February 2022 (UTC)

Multiple movement types

Skill Advancing Strike features two movement types: first it leaps and then shadowsteps if the target is in range after the leap. Could someone please add support for listing multiple movement types? --Genie (talk) 21:21, 11 June 2023 (UTC)

Slot: Mastery?

We have multiple mastery skills now across two expansions, probably makes sense to add support for this type of skill here. Genie (talk) 08:31, 2 September 2023 (UTC)

Seems like User:Noxx has provided, including a new page for Mastery skills. Looks great. ~Sime 00:49, 4 September 2023 (UTC)

And I hadn't even noticed this suggestion here before, I just felt like we really needed that page as well and went from there. But I'm glad I wasn't the only one to think so. ^^ 06:44, 4 September 2023 (UTC)