Template talk:Skill fact

Archive

---

• /Archive 1

Varying duration value notations

Sample case. This might happen in the future, and I really don't know how to properly account for these. We could use 180secs for duration param sure, but it would look so out of place. I've been thinking about expanding misc and add a "flavor" parameter so we can avoid html tags all over this template, they just... don't feel right. We could simply wrap flavor text around a grey span (I'm sure this is how it goes for 99.9999999% of skills). Thoughts? – Valento ^msg 18:30, 29 January 2015 (UTC)

Breakstun Icon

In the game, the breakstun icon in the tooltips of skills that break out of control effects is a chain being snapped in half. I think we should change the icon of breakstun from it's current stun icon to what is in the game. Nicoli20 (talk) 00:11, 18 March 2015 (UTC)

Wow, that's been broken for a while, good catch. —Dr Ishmael 01:55, 18 March 2015 (UTC)

Skill fact rewrite

Skill fact rewrite is pretty much done. This involves a rewrite of the {{effect}} template at the same time. I went through most of the skills and traits and picked out anything that occurred often. That's where you see gain and remove from. The rest is factoring out the miscellaneous parameters, adding effect descriptions to everything, supporting effects, making generic properties, having a useful default case (pretty much replacing misc). Some facts like pull and area of effect don't appear anymore. I also fixed the example tables to make it more useful as a reference. I can add backwards compatibility, but stuff is going to break in any case and might as well fix everything. This makes the specific effect templates obsolete and most of them won't be affected by the changes to the effect template.--Relyk ~ talk < 00:26, 28 June 2015 (UTC)

Attunement and linked skill could be combined, since attunements are skills. —Dr Ishmael 01:38, 28 June 2015 (UTC)

How to use {{skill fact|property|(property name)|(value)}}? I wanted to implement it in https://wiki.guildwars2.com/index.php?title=Confounding_Suggestions&oldid=1032714 but it gave a error saying "The given value was not understood". Thanks. (The page used {{skill fact|Trigger Chance|100%}}. I tried {{skill fact|property|Trigger Chance|100%}} but still in vain.) --Fanolian (talk) 05:26, 29 June 2015 (UTC)

Health threshold (skill fact|threshold) should use a radius icon instead of the generic one. --Fanolian (talk) 06:48, 29 June 2015 (UTC)

It was an issue with {{trait infobox}}. threshold needs to be changed to health threshold eventually. There are a couple other threshold facts like range that use the generic fact iirc. Didn't add them becomes they were uncommon.--Relyk ~ talk < 07:02, 29 June 2015 (UTC)

In the section of Percentage modifiers, {{skill fact|duration increase}} does not support alt text while the other 3 do. This is a minor issue as I can always use {{skill fact|property}} for this type of property. It is just a matter of consistence (in the reference). :) --Fanolian (talk) 07:18, 29 June 2015 (UTC)

It's intentionally not consistent, the ones with alt text are the skill facts I saw needed alternate text. Another problem with duration increase is that there are duration facts for a fixed amount of seconds. I figure people should use a general property for those edge cases.--Relyk ~ talk < 08:01, 29 June 2015 (UTC)

Understood. I am editing Temporal_Enchanter but I cannot use {{skill fact|property|Duration Increase|2 s|icon=Radius.png}} to change the icon. For the example given in Template:Skill_fact, {{skill fact|Hits per Shell|5|icon=Stun.png}} works but not {{skill fact|property|Hits per Shell|5|icon=Stun.png}} --Fanolian (talk) 08:09, 29 June 2015 (UTC)

Property doesn't overload the icon parameter because all properties use the generic icon. If it's using a specific icon and terminology, the template needs to parameterize that. I think we need the template to be smart about checking whether the value is a percent or integer increase and format correctly--Relyk ~ talk < 08:14, 29 June 2015 (UTC)

The percent sign is annoying. We could use decimal values instead of requiring a percent sign if we assume no duration increases go below 1.--Relyk ~ talk < 08:29, 29 June 2015 (UTC)

Is there a way to distinguish 20% and 100% physical finishers now? Before it is done by {{skill fact|combo|projectile|suf=(20% chance)}}. Thanks. --Fanolian (talk) 09:40, 29 June 2015 (UTC)

I fixed the combo template earlier and forgot to add an example. I added an example, you specify y on the third parameter.--Relyk ~ talk < 18:46, 29 June 2015 (UTC)

That's... not intuitive at all. I'm not sure I like all the unnamed parameters that do different things depending on the value of the first one. —Dr Ishmael 18:54, 29 June 2015 (UTC)

How do I modify the display name of an effect? Decoy, for example, stealths but grants Hide in Shadows (effect). I tried {{skill fact|effect|[[Hide in Shadows (effect)|Stealth]]|3}} and {{skill fact|effect|Stealth|alt=Hide in Shadows (effect)|3}} but both fail. Another example is Protected Phantasms. The effect it grants is Phantasm Distortion instead of Distortion. But this one is really an edge case. In another news, most descriptions for stealth are broken due to the unavailability of {{skill fact|stealth|3}}.

The stack of stablility cannot be displayed, i.e. {{skill fact|stability|2|stacks=3}} is shown as

₃ Stability (2s): Cannot be knocked down, pushed back, pulled, launched, stunned, dazed, floated, sunk, feared, or taunted..

I've restored stacks to boons.

@Relyk: Why did you completely remove the ability to customize some options? Every option should be able to change the icon and the display text. Furthermore, every parameter listed in the generic "Parameters" section should be usable by every option. —Dr Ishmael 12:21, 29 June 2015 (UTC)

I didn't remove the ability to customize. You can customize the skill fact if you don't provide a type. The parameters section is not a generic list. We can change it to show which skill facts use specific parameters, like coefficient does.

We can provide a desc parameter to override the description for effect and have alt override the link text. The mismatched effect and link text was an edge case that I figured we'd push to the default case ({{skill fact|[[Hide in Shadows (effect)|Stealth]]|3 s|icon=Stealth.png}}), but we want the effect case to handle those.--Relyk ~ talk < 18:24, 29 June 2015 (UTC)

Given how the documentation is written, it looks like strikes and stacks should be usable no matter the value of parameter 1. But that's obviously not the case, so that needs to be rewritten to specify exactly when strikes/stacks can or can't be used. —Dr Ishmael 18:57, 29 June 2015 (UTC)

Should all boons and conditions be able to stack? Here's a screenshot all boons and conditions with stacks=5 appended: http://i.imgur.com/mS9d0nh.png. In addition, boons/conditions that stacks but having 1 stack only do not have an extra space between their icon and text, where the number of stacks should have been. Immobilize is the exception. It does not stack nor have an extra space. It looks bad in the template page. --Fanolian (talk) 04:36, 30 June 2015 (UTC)

One stack is implicit so we don't show it.--Relyk ~ talk < 16:14, 30 June 2015 (UTC)

Is it now safe to replace the misc calls in various trait skill facts with the new increase / decrease modifiers? I figured I'd go through Necro traits or something if it was. --Silenceaux (talk) 17:36, 29 June 2015 (UTC)

It should be because I didn't see any other edge cases.--Relyk ~ talk < 18:24, 29 June 2015 (UTC)

Use Template:Effect icon instead

Notably Daze and Stun have text errors in their description, putting articles like Mirror of Anguish into Category:Text errors. Without hovering over the icons, I never saw any text error on the articles that transclude those effects and this was very misleading—MoA didn't use {{sic}} or [[Category:Text errors]]. I had to dig through the DOM / ExpandTemplates to figure out what was causing this. Instead of {{effect|Daze}} can we do {{effect icon|Daze}} [[Daze]]? For all the effect icons? Mouseover description is redundant on effects (e.g. like Resistance) that display description afterward. —BryghtShadow (talk) 01:35, 7 July 2015 (UTC)

Mirror of Anguish is adding the page to Category:Text errors with {{effect description}}. You can see why that happens on Special:Browse/Daze. The actual problem is the sic being included when we define Property:Has game description in {{effect infobox}}. We can strip the template call out before defining the property.--Relyk ~ talk < 11:34, 7 July 2015 (UTC)

Oh yes, I'm all for the removal of sic when defining the property. --BryghtShadow (talk) 03:16, 8 July 2015 (UTC)

How exactly do you plan on doing that? The {{#replace}} function only works with literal strings, it can't do regex. And with {{sic}} taking a parameter (to describe the error), you can't just replace a literal. —Dr Ishmael 04:16, 8 July 2015 (UTC)

Like this!--Relyk ~ talk < 07:19, 8 July 2015 (UTC)

Well frak. I completely forgot about #dplreplace and that SMW pre-parses the values of text properties. Anyway, better get this on the other infoboxes, too. —Dr Ishmael 12:29, 8 July 2015 (UTC)

{{#dplreplace: What if the darn thing hasn {{sic|should be has}} more than one typoe {{sic|should be typo}}? |<span(.*)</span>|}}

What if the darn thing hasn ?

Maybe use something without greedy .* in it? -Chieftain Alex 12:40, 8 July 2015 (UTC)

{{#dplreplace: What if the darn thing hasn {{sic|should be has}} more than one typoe {{sic|should be typo}}? |<span(.*?)</span>|}}

What if the darn thing hasn ]]] more than one typoe ]]]?

That's even more fun, because template:sic has nested <span>s. —Dr Ishmael 12:47, 8 July 2015 (UTC)

{{#dplreplace:What if the darn thing hasn {{sic|should be has}} more than one typoe {{sic|should be typo}}? | /(.*?)\s?(<span.*?>[''\[\[wikipedia:sic\{{!}}<span.*?>sic<\/span>\]\]'']<\/span>)(?:\[\[category:text errors\]\])?/i|\1}}

What if the darn thing hasn more than one typoe?

See: "de-sic". Also removes the cat. --BryghtShadow (talk) 14:58, 8 July 2015 (UTC)

Yuck. I don't really like the idea of putting a lot of complex regex into our templates. It should be sufficient to simply remove the category and leave the sic tag, and that doesn't require any regex at all. —Dr Ishmael 15:10, 8 July 2015 (UTC)

Would it be horrible to suggest that we make each one of these skill facts into a subobject if used on a skill page? (defined for example by a variable in the infobox) It would be nice (read: I like popup hover things in my sandbox) to have a way to reproduce effects on another page. -Chieftain Alex 15:21, 8 July 2015 (UTC)

That was already planned until someone removed the proposal from Guild Wars 2 Wiki:Semantic MediaWiki/Skills :P One of the main reasons for the rewrite is defining more effect types and generalizing to make subobjects useful.--Relyk ~ talk < 15:11, 9 July 2015 (UTC)

this bit? What is set_internal anyway? #subobject? -Chieftain Alex 16:30, 9 July 2015 (UTC)

smw:Semantic Internal Objects - it's deprecated now in favor of subobjects. Originally an SIO worked something like an inverted subobject where the relationship pointed from the SIO to the parent page (and you had to specify the name of this property when creating the SIO), rather than the relationship being defined in Property:Has subobject pointing from the parent page to the subobject. —Dr Ishmael 16:44, 9 July 2015 (UTC)

I used the regex that targetted sic's format to avoid removing markup from other possible sources. I also chose to remove the leading space for scenarios where the {sic} was added before a punctuation. Here's a simpler one (is this still too complex?) that still removes leading space:

pattern = (.*?)\s?<span.*?>.*?<span.*?>sic</span>.*?</span>, replacement = \1

What if the darn thing hasn more than one typoe?

Simply removing the category may be sufficient, but the properties will still be filled with so much markup: [1]. I prefer my properties as clean as possible. IMO, markup from {sic} doesn't make sense for description, whereas linebreaks do (game uses '\n'). --BryghtShadow (talk) 16:15, 8 July 2015 (UTC)

The simple method is add id="outer-span" and do <span id="outer-span"(.*)] I'd think. Removing the category is the most elegant solution though because the normal use for {{effect description}} should still have the sic.--Relyk ~ talk < 15:11, 9 July 2015 (UTC)

"normal use should still have the sic" That's exactly what I was thinking when I suggested that. —Dr Ishmael 15:21, 9 July 2015 (UTC)

Costume brawl missing

It seems the costume brawl parameters aren't used by this template anymore. This breaks facts in a lot of skill pages. Tyndel (talk) 06:20, 7 August 2015 (UTC)

Ok, we just use the effect parameter, makes sense. We could use a bot to update the skills that are affected. EDIT: And now I'm seeing it's already at work lol... Tyndel (talk) 08:20, 7 August 2015 (UTC)

manual editing with AWB sucks - the variables were too randomly written for a bot >.< -Chieftain Alex 08:57, 7 August 2015 (UTC)

Defiance bar damage and pull, knockback and launch disable durations

I think pull, knockback and launch should have an additional parameter for the disable duration. Pulls and knockbacks seem to always have 1.5s so that could be the default. Launches have 2.32 or 3.23. Listing defiance damage is but questionable since it can be calculated from the effect and duration. Conditions might look messy if they had defiance value on them. I didn't want to start editing the template right away in case I mess up royally. Any opinions? Wethospu (talk) 06:48, 5 May 2016 (UTC)

pre/suf options

Ran into suf= for the first time today while working on Asura Ice Wave, which seemed like a handy way to get some extra text into the skill fact where it was needed. However, it's use and existence aren't documented on the main page. Same thing with pre=, which I assume has a similar purpose. Could an example be added? SarielV 04:51, 12 May 2017 (UTC)

The pre and suf parameters were there to generalize the template. After refactoring the template, I think this turned out to not be needed when I was working on it. This became even less so as AreaNet standardized most of the skill descriptions. Right now, they are only for backwards compatibility and I couldn't find any examples where we are still using them.--Relyk ~ talk < 18:59, 26 July 2017 (UTC)

Property

What exactly is "property" supposed to be used for? It looks like it does the same as "misc", just you can't change the icon. What am I missing here? - Do_odleplex 22:02, 21 March 2018 (UTC)

Daze and the other Daze

I noticed that there are two different Icons and discriptions for daze and stun in the game. Launch Personal Battering Ram has one of the "other" daze instances where the skill fact isn't Daze: 1 second but Daze(1s):Unable to use skills.. As far as I'm aware this template isn't covering that case. The alternative skill fact for stun is Stun(Xs): Unable to act. as seen on the skill Shocking Bolt. Both have different icons than the standard daze and stun. --Saphir (talk) 12:40, 29 February 2020 (UTC)

Thanks, good call. I was aware that there is a different daze text, but not that these have a different icon too, e.g. Head Shot. Added "daze alt" and "stun alt".

Skill fact	Example	Display	Icon prior to July 7, 2020	Icon after July 7, 2020
daze	{{skill fact|daze|3}}	Daze: 3 seconds	(gray)	(purple)
daze alt	{{skill fact|daze alt|3}}	Daze (3s): Unable to use skills.	(purple)	(purple)
stun	{{skill fact|stun|3}}	Stun: 3 seconds	(gray)	(purple)
stun alt	{{skill fact|stun alt|3}}	Stun (3s): Unable to act.	(purple)	(purple)

--Tolkyria (talk) 14:10, 29 February 2020 (UTC)

Adding clarification (last two icon columns in the table above) as the icons got unified with the July 7, 2020 game update: "Icons for daze and stun are now displayed in light purple in skill and trait tooltips.". There are also daze gray and stun gray to get the old icon variant for skill and trait version history pages. --Version history (talk) 17:57, 30 April 2021 (UTC)

Clean-up

I would like to clean up this template a little bit. Points that I think we should somehow address are:

• The options "property", "misc" and default are able to produce the same output and hence sometimes all three are used for one and the same in-game skill fact, resulting in inconsistent usage. E.g. the following are all used in skill descriptions:

{{skill fact|property|Number of Impacts|5}}
{{skill fact|misc|alt=Number of Impacts|5}
{{skill fact|Number of Impacts|5}}

• The option "misc" requires the parameter "alt" instead of unnamed parameter 2 (with the default Miscellaneous effect that's never used), which is pretty clunky to use. Furthermore, there are two parameters to set an icon, namely "icon" (e.g. matching the name with the skill/trait infobox parameter "icon") and the parameter "image" (I would remove this), again, creating unnecessary inconsistencies.
• Several "misc" calls could be replaced with "effect".

Do we actually need all three of these parameters ("property", "misc" and default), or can we reduce it to two (e.g. keeping default as it's kinda inevitable to have it and merge "property" and "misc" into "property") or even reduce it to one (e.g. merge "property" and "misc" into default).

I'm actually thinking of removing "misc" and "property" and merge them into default. However, there might be an already predefined fact that now reappears with a modified fact description and icon, and hence we would have to keep one of those, but definitely it would be used rarely. E.g. Bone Crack (Bone) has some wierd "stun" description, here we would need and additional parameter, e.g. "property" or "misc" that allows to bypass the predefined "stun" icon and description.

Any thoughts? --Tolkyria (talk) 00:38, 3 December 2020 (UTC)

Condition Effect Reduced

What the heck is "Condition Effect Reduced"? Is there an in-game equivalence to this "fact". A quick query shows that all of them are set silently. Please keep in mind that the wiki is here to document the game, not to create stuff you would like to see in-game. Where's the in-game expression of it? --Tolkyria (talk) 08:04, 19 October 2021 (UTC)

See Immobile#Traits_that_reduce_the_effects_of_immobilized, Chilled#Traits_that_reduce_the_effects_of_chilled, Crippled#Traits_that_reduce_the_effects_of_crippled. I'm going to change the description so it's the same as the already defined conditions, then it'll replace those skill facts so those skills can be automatically listed. It'll have to wait until after the wiki maintenance though. --BuffsEverywhere (talk) 11:58, 19 October 2021 (UTC)

Well, that's pretty obvious based on the query, yet there's no indication that the term "Condition Effect Reduced" exists in-game. Arguing that there for example "Condition Effect Ignored" exists doesn't really justify it in my opinion. While we are bound with the displayed facts to what is present in-game skills, we can adjust the fact type more or less freely to our needs.

No offense, but may I suggest to go one step back during an edit rampage (like e.g. temporarily adding a recursive template call) or maybe use the talk page and describe your problem, sometimes one gets the solution just with writing down the problem. Because in my opinion you had been almost there but yet failed to see the overall picture.

So one step back, what is your so called "Condition Effect Reduced" and how are they documented in the skills/traits?

• In-game they are displayed as simple conditions with a duration equals to 0, which is omitted, while in calculations (e.g. for condition damage) the are using a duration of 1 seconds. There is no fancy text like "Condition Removed" or "Condition Effect Ignored", just the normal condition text.
• On the wiki we currently document them as normal conditions with a duration of 0, e.g. {{skill fact|chilled|0}}. Then however we have to exclude those on the condition overview pages with number=>>0.

Basically everything should be here, on the wiki they are only differing by the subobject property Has fact type. So what about introducing a third parameters for boons and conditions that allows to set the type, for example here we would set {{skill fact|chilled|0|Condition Effect Reduced}}.

This would:

1. Avoid to define all the condition description text in the template again.
2. Eliminate setting them as missing facts (which after your intended redesign probably won't be done either)
3. Solve the problem with boons/conditions of duration 0 that are no boon applications but anything else.

Questions if we agree on this solution:

• How to set it? Is type={{{3|Condition}}} sufficient enough? Are there any incorrectly used skill facts that have an empty unnamed parameter 3 which would mess up the declaration?
• Would be a parameter called type better than unnamed paramter 3 (as it's not a fact-related parameter but rather a subobject-related parameter)?
• Where to set it? Are boons and conditions enough?

--Tolkyria (talk) 13:29, 19 October 2021 (UTC)

You're right. I was too hasty in trying to come up with a solution and didn't test it first. I wanted to make the usage the same as "condition effect ignored", so it would be easy to use and avoid switching around the order of the parameters. But I do like your solution as it is easier to implement and allows for other types in the future. I suggest going with the type parameter so users won't have to remember to define or skip unnamed parameter 2. I think boons and conditions could be enough but I'm not sure. --BuffsEverywhere (talk) 02:36, 20 October 2021 (UTC)

I thought twice before even suggesting it, as it's indeed a completely new approach which probably questions how we handle other skill facts, but it should be the only reasonable way to do it. The alternative as you initially planned would be to create 12 "duplicate" boon facts and 14 "duplicate" condition facts where in the end only the Has type fact would have differ.

I agree, paramter type is 1. much more precise for such an important annotation and 2. much safer as it can't really be set unintentionally (unlike unnamed parameter 3). --Tolkyria (talk)

Defiance bar value

As per discussion on official forum regarding breakbars, one of the users would like the defiance bar value for every CC skill listed on the skill's page. https://en-forum.guildwars2.com/topic/104658-the-breakbar-gate/?do=findComment&comment=1512647
I'm not sure this is worthwhile but if people agree then it would probably be incorporated into the skill fact template as "breakbar value" or similar probably. --Life Infusion «T» 19:54, 15 November 2021 (UTC)

That's not our task unless the devs decide to actually add this information in the skill facts. Visually, the skill facts are purely mirroring the in-game skills facts, in my opinion there's no room for interpretation.

Of course we could add to the Notes section something like "Deals N defiance bar damage." manually or even calculate it automatically based on the control effect skill facts but these two options have nothing to do with this template.

Furthermore, isn't Defiance bar#Skill details sufficient enough as it combines all skills that deal defiance bar damage nicely on one page? --Tolkyria (talk) 21:36, 15 November 2021 (UTC)

Okay , I was just checking if it needs to be in the template as a breakbar value or something akin to that. Adding it to the notes section of every skill with hard CC is going to be quite tedious , personally I think it should only be on skills with odd values such as those with launch. The users on that thread stated they didn't see it on the skill specific page, I had linked them the defiance bar page already. --Life Infusion «T» 04:42, 16 November 2021 (UTC)

Fury

From the ArenaNet Studio Update: June 2022: "We’re making the critical-hit chance from them much more accessible by increasing the critical-hit chance bonus from the fury boon from 20% to 25% in PvE [..]".

Brainstorming a bit how we could solve it, as the parameters should be

1. backwards compatible without requiring any edits to all existing occurences, e.g. skill and trait /history pages,
2. but also easy usable.

So we could keep the current "fury" option to state +20% and create a new "fury 25" option which states +25% (or would it be better to set the unnamed parameter 3 to "25" from the option "fury", see alternative version below). Note that this version would require the manual usage of the infobox parameter "split" and the skill fact parameter "game mode":

{{skill infobox
| split = pve, wvw pvp    OR    pve, wvw, pvp
...
| facts = {{skill fact|fury 25|5|game mode=pve}}{{skill fact|fury|5|game mode=wvw pvp}}
...
}}

Alternatively, it could be also:

{{skill fact|fury|5|25|game mode=pve}}{{skill fact|fury|5|game mode=wvw pvp}}

In my opinion this solution is full backwards compatible and relatively straight forward to use. I also thought about implementing the game mode split into this template but discarded it pretty quickly as it's not really backwards compatible if they revert it in the future and it still requires the infobox parameter "split" to be set.

Any opinions or suggestions, of course depending on how it will ultimately look like in the game. --Tolkyria (talk) 20:00, 22 June 2022 (UTC)

After thinking about it I'm preferring the unnamed parameter 3 variant to the standard option "fury" to define another critical strike chance beside the default 20%. This approach is flexible (it would allow any other critical strike values, e.g. traited ones if necessary), backwards compatible and also straight forward to implement.

The code would look like the following, where the first unnamed parameter is the skill fact "fury", the second second unnamed parameter stands for the duration (here: "5" for 5 seconds) and the optional third unnamed parameter for the critical chance (here: "25" for "+25% Critical Chance"):

{{skill fact|fury|5|25|game mode=pve}}{{skill fact|fury|5|game mode=wvw pvp}}

--Tolkyria (talk) 18:15, 23 June 2022 (UTC)