Template talk:Trait infobox

So, what's needed here? Minor/major trait, weapon or whatever it's for, class (if applicable), a picture (obviously), and I think that's it. Traits for all classes could be called Universal Minor/Major traits, perhaps. Color needs to be decided upon: probably some variation of that kind of orange that they use for the traits UI right now. —ǥrɩɳsɧƴɖɩđđɭɘş 16:04, 16 March 2011 (UTC)

See Talk:Trait. I already had brought this up, people like the format I am about to upload. Let me know what you think. Aqua (T|C) 01:59, 20 March 2011 (UTC)

Ready for implementation, 22 changes later. Aqua (T|C) 03:31, 20 March 2011 (UTC)

Looks nice and ready, in my opinion. - Infinite - talk 03:37, 20 March 2011 (UTC)

Needs one more improvement: multiple profession specific lines for things like: "Superior Power" which are in more than one trait line. Aqua (T|C) 03:40, 20 March 2011 (UTC)

Now that that is ready. I believe everything is set up and good to go. Aqua (T|C) 04:04, 20 March 2011 (UTC)

Nice work guys. Looks good :) --Moto Saxon 05:44, 20 March 2011 (UTC)

Isn't there a way to change the template so it says "Profession" instead of "Profession(s)", and only uses "Professions" if there are more than one profession selected? Also, for some of the traits the "Line" section is actually breaking in two lines instead of one (as seen here). Is there a way to expand the size of the infobox so that kind of thing doesn't happen? Erasculio 02:09, 21 March 2011 (UTC)

To my mind somewhere in the info box there should be a hyperlink to trait. For example in the line "Trait Line | " | Corvus 21:12, 23 June 2011 (UTC)

Color

Discuss. I like the current color, but if there is a more appropriate color, I would love to see it. Aqua (T|C) 17:48, 20 March 2011 (UTC)

We should leave the colour discussion to the grouping of various colours. I don't like random colour picking based on what looks nice. :P - Infinite - talk 18:06, 20 March 2011 (UTC)

Icons

Most pictograms in the icons are shared between several traits. We need to avoid uploading a new image each time. I don't think that "icon file defaults to [[File:<page name>.png]]" is a good idea. Also, please, refrain from calling a template "ready" 33 minutes after your last edit. I wish I had a chance to give my opinion before it's deployed on the whole wiki. Chriskang 09:52, 21 March 2011 (UTC)

I figure if the parameters are ok the appearance can be changed easily enough. I'm hoping this will eventually end up matching the skill infobox style (whatever that ends up as). -- aspectacle  11:09, 21 March 2011 (UTC)

The parameters are not ok. We know that traits are acquired in pve by completing some challenges and it wasn't even discussed if this information should be in the infobox or not. IMO, it should be (not the whole quest but at least the NPC giving the challenge, just like skill trainers appear in the skill infobox). Also as I said in my first post, the icon parameter is not correct either. There should be 2 parameters: one for the pictogram, another for the background-color and the icon should be rebuild with (type + pictogram + color). Chriskang 14:15, 21 March 2011 (UTC)

We have absolutely no idea how acquisition works, we don't even know if it is as simple as an NPC issuing a quest. Besides, if I had implemented acquisition at this time, I would have had to delete it from all 200; it wouldn't have been used save for a single, profession specific, trait. Also, the pictogram background-color method doesn't work really...That worked when the traits were constrained to a single line, not when they spanned approximately 3-4 lines (maybe it could work, but I don't believe so: I'm going to test it shortly afterward). (In addition Chris, you had 5 days to voice your concern with the formatting before I even made the template, and you were active while I was creating the template. The template was ready for deployment given our knowledge of how the trait system worked, and any changes now will effect each page, and thus not require too much editting. In addition, I doubt we will fully understand trait acquisition for some time, so for now that can take a lower priority. ) Aqua (T|C) 16:44, 21 March 2011 (UTC)

You can say that a consensus is reached 5 days after the end of the discussion, not 5 days after the beginning. Otherwise, the {{skill infobox}} template is ready since May 2010 ;) Anyway, forgive my poor English skills but I don't understand this sentence "That worked when the traits were constrained to a single line, not when they spanned approximately 3-4 lines". Care to elaborate, please? Chriskang 18:04, 21 March 2011 (UTC)

I am going on the assumption that you were referring to a system similar to our current {{Trait icon}} system. That works on a single line, where only one span style is necessary. I am unsure if that works on trait icons greater than the height of one line. Aqua (T|C) 21:36, 21 March 2011 (UTC)

It'll work perfectly. Don't worry. Chriskang 22:36, 21 March 2011 (UTC)

Not entirely sure how to make that work...:S I tried, but it doesn't quite function properly. Aqua (T|C) 01:16, 22 March 2011 (UTC)

rowspan="3"? - 84.31.15.202 01:30, 22 March 2011 (UTC)

(Reset indent) Already has been implemented, no success. Aqua (T|C) 01:35, 22 March 2011 (UTC)

I'll do it Aqua, just give me a few days please. I don't have that much time ATM. Chriskang 08:35, 22 March 2011 (UTC)

engineer traits

We have some now some information about Engineer traits, see the picture in Trait. So how can this be incorporated in this template?? Balwin 18:37, 29 June 2011 (UTC)

What specific information are you referring to? Aqua (T|C) 19:05, 29 June 2011 (UTC)

Probably the 4 Primary trait lines. - Infinite - talk 19:12, 29 June 2011 (UTC)

Yes, I was refering to the trait lines and specific to the list of traits in the Inventions line. There was no parameter for an engineer trait line in the template and I did not know how to add one. Now there is a parameter ("en-line=") and everything is fine :) Balwin 07:58, 1 July 2011 (UTC)

Categories

Would we want to have this template categorize traits into Major and Minor? Or would we want (Profession) Major and (Profession) Minor? Or not at all? --JonTheMon 19:56, 22 February 2012 (UTC)

Anyone? --JonTheMon 14:51, 23 February 2012 (UTC)

DPL would argue we don't need <profession> major/minor trait categories, so I'm inclined to go with that. List of <profession> traits can apply the DPL after all, no need for separate categories. (Much like we still need to sort out the other mixed categories.) - Infinite - talk 14:54, 23 February 2012 (UTC)

So... I'm not sure what you are actually supporting. --JonTheMon 15:05, 23 February 2012 (UTC)

Globally categorizing them in minor and major, also within separate parent categories for trait lines. Optionally (though I don't find it necessary) with sub-categories for the trait rarities/types. Then DPL the combination on articles to list them by combining them with the profession (or, more specifically when required, trait lines). - Infinite - talk 15:11, 23 February 2012 (UTC)

Well, one of my plans is to categorize the majors into cat:major, then the minors into cat:minor with sort keys 1,2,3 based on adept,master,grandmaster. Also, if it's visually displeasing, would we want these categories to be hidden? --JonTheMon 15:14, 23 February 2012 (UTC)

I wouldn't mind them appearing, so I'm indifferent and will leave it to others to discuss further. Either way, your plan sounds fine. - Infinite - talk 15:18, 23 February 2012 (UTC)

Types vs tiers

So how are we going to use these? The old way, we had just type, but it had major and minor(adept,master,grandmaster). Are we switching it so that both tier and type are used for both types (major,minor [which comprise the type field]) and all traits are also categorized by (adept,master,grand)? --JonTheMon 14:57, 11 June 2012 (UTC)

Also, if so, how are we going to go about transitioning the traits? --JonTheMon 14:57, 11 June 2012 (UTC)

I'm in the process of transitioning the traits (including updating descriptions etc.). For this table, I think we need to show both, and now it would make more sense for tier to be the "top" category (adept/master/grandmaster in the leftmost column), then type (minor/major). —Dr Ishmael 15:09, 11 June 2012 (UTC)

Right now, the traits are categorized into two hidden cats (major/minor) and previously they were given a sort key for adept/master/grandmaster, do we want to retain those for the new system? Or are we going to do away with that in anticipation of SMW? --JonTheMon 16:59, 12 June 2012 (UTC)

I wasn't entirely sure about how to handle that, which is why I left the existing type categories without adding tier categories. SMW won't need either set of categories, but for now, we should probably add the tier categories for DPL to work with. —Dr Ishmael 17:45, 12 June 2012 (UTC)

One nice thing about the type with the sort key was the ability to easily sort them. Adept/master/grandmaster are a little harder to auto-sort. --JonTheMon 19:35, 12 June 2012 (UTC)

(Reset indent) Since we're now switched over, do we want to re-introduce the sort keys? --JonTheMon 14:02, 14 June 2012 (UTC)

Done, and I think this looks good unless we want to do a full overhaul of {{trait table}}. I'll probably do that anyway when we switch it to SMW. —Dr Ishmael 01:19, 15 June 2012 (UTC)

Icon parameter: make it simple! :)

Why don't you replace the icon parameter for number or something, so that you only pass the number (1–12) and the template auto-recognize the apropriate the icon? I'll be implementing this in our wiki so that this bit of information becomes easier and more consistent to gather for our build calc. – Valento ^msg 07:47, 14 August 2012 (UTC)

Implemented! Categorization is much cleaner, and you only have to pass a number as the parameter for icon: 0 for minor trait (this sortkeys the trait under '0'), and 1–12 for major traits (this still sortkeys correctly). One thing to be noticed, the icon is used to define the sortkey, but you avoid that hardcoding. :) – Valento ^msg 08:09, 14 August 2012 (UTC)

You could avoid using a variable too, that switch is fairly simple, but for readability it's better to make use of it. – Valento ^msg 08:12, 14 August 2012 (UTC)

Changed the code a little bit to default icon to when there's no icon parameter specified, it's a bit redundant to ask a number for minor traits since they all use the same fire icon. – Valento ^msg 20:54, 14 August 2012 (UTC)

In a generic infobox, the icon parameter takes the full filename in order that it can be the most flexible - that's the point of having an icon parm to begin with. I think we should leave icon alone (for the rare cases like Stick and Move, and in case Anet surprises us all and gives every trait a unique icon at launch) and instead add a distinct numeral parameter. That way, minor traits default to "Trait fire.png" and major traits default to "Trait {{{numeral}}}.png", and icon can override both of those defaults.

Q: should it be numeral or number? There's going to have to be a conversion somewhere either way, since we need the numeral for the filename and we need the number for the sortkey. I'd favor numeral myself. —Dr Ishmael 21:05, 14 August 2012 (UTC)

You're absolutely right about ArenaNet giving each trait an specific icon, I can make both parameters available or you can do this yourself, and I vote for numeral too. I really believe the code is a little hard to understand. – Valento ^msg 21:09, 14 August 2012 (UTC)

One more thing, why do you accept even the image extension (e.g. ".png") in that parameter? isn't all traits/skills png anyways? – Valento ^msg 21:13, 14 August 2012 (UTC)

That's part of being flexible. Also, the Gw2.dat-extracted PNG icons are fairly recent (in the history of the wiki), they used to be primarily JPG. —Dr Ishmael 21:33, 14 August 2012 (UTC)

Yes, I remember all those .jpg images for skills, this reminds me of deleting them as well. Btw, will you apply the changes to the template so I can synchronize with our wiki? – Valento ^msg 21:45, 14 August 2012 (UTC)

I'll do it later, probably after dinner, when I'll have time to set up a bot run to update all the trait pages. I've already updated the code and saved it here in order to test it (by editing a trait page to use my template and previewing), and it seems to work fine. —Dr Ishmael 21:50, 14 August 2012 (UTC)

Funky parentheses appearing since wiki update

See, for example, Thick Skin. --Alad (talk) 01:07, 9 May 2013 (UTC)

The semantic datastore is being rebuilt. You can null-edit pages to help it along (in this case, I did that to Defense and then this page). —Dr Ishmael 01:13, 9 May 2013 (UTC)

Oh cool. And "null-edit" means? :D (I guess it means starting an edit, changing nothing, and saving?) --Alad (talk) 01:47, 9 May 2013 (UTC)

Yup exactly, just hit edit and save without changing anything. This forces the parser to update everything about the page. poke | talk 02:15, 9 May 2013 (UTC)

Is someone rolling changes to this infobox?

We must make the template accept specialization instead of line, and many traits with their titles ending in "(trait line)" should be replaced by "(specialization)" or simply "(spec)". I can go over them if you allow me! – Valento ^msg 19:17, 23 June 2015 (UTC)

Use line for now, we can do a bot run later to update all the pages. —Dr Ishmael 19:24, 23 June 2015 (UTC)

Ok! Can't wait for the new icons!! Exciting times! – Valento ^msg 19:29, 23 June 2015 (UTC)

I just performed a quick and dirty cleanup of all the old, deprecated junk (like numerals and stuff). Let me know if it broke anything. —Dr Ishmael 20:44, 23 June 2015 (UTC)

Other than the fact that most traits won't have their shiny new icon yet, and retired traits will never have one. I know I borked that all to hell. :P —Dr Ishmael 20:45, 23 June 2015 (UTC)

I'm about to run a bot to remove the numeral parameter from all instances of this. —Dr Ishmael 13:40, 24 June 2015 (UTC)

Press dat button with no regret! – Valento ^msg 14:21, 24 June 2015 (UTC)

Already done. :P —Dr Ishmael 14:51, 24 June 2015 (UTC)

I changed everywhere that mentioned "trait line" that I could find, this includes some page titles. It is safe to use "specialization" for most things now. You forgot to change the line parameter name to "spec" or "specialization" though. Not sure if you want to spend more time for that! >.< – Valento ^msg 19:55, 25 June 2015 (UTC)

Trait number

Should a trait number parameter be included to help indicate what order in the "Training" each is unlocked and format it to show "top/middle/bottom"? —Mora 23:18, 24 June 2015 (UTC)

This could be somewhat mentioned in traits tables for every profession/specialization. I think it would cause some confusion if displayed in the infobox, Mora. – Valento ^msg 19:53, 25 June 2015 (UTC)

The order would be mentioned on the Training article. The order the traits unlock isn't helpful to us anywhere else.--Relyk ~ talk < 20:06, 25 June 2015 (UTC)

The Training article isn't going to list every trait order, that is why it'd be much more useful to have it ordered correctly in the {{trait table}}. And if those are going to continue to be automatic lists, it could just use a hidden property on each trait's page. —Mora 20:17, 25 June 2015 (UTC)

That wouldn't hurt IMO, but I believe Ish will have a whole different opinion. :P – Valento ^msg 20:24, 25 June 2015 (UTC)

Why would we order by trait unlock in the trait table? That makes no sense. We will list the order on the Training page or a subpage for each profession if it's too long.--Relyk ~ talk < 20:36, 25 June 2015 (UTC)

Because the trait interface is very visual now. Listing them in alphabetical order serves no benefit to readers. —Mora 20:40, 25 June 2015 (UTC)

The trait table doesn't list traits in alphabetically order.--Relyk ~ talk < 02:31, 26 June 2015 (UTC)

Yes, the Major traits ("top/middle/bottom") in each tier are in alphabetical order. —Mora 02:47, 26 June 2015 (UTC)

True - I guess we need a parameter to identify the position. Being able to display the traits in the same order as the GUI would be excellent. -Chieftain Alex 10:12, 26 June 2015 (UTC)

Related skills! Moving focus

So, I'm moving the focus from this discussion here. Ideally we'd have to store which skills a trait affects, and then query from it in the skill infobox template by looking up PAGETITLE. Not sure how to query it, but I'd be more than happy to help filling which skills each trait affects. We'd need a new multi-value property/parameter, maybe named relatedskills? What you do with them on the other side, though, is something I lack skills to articulate (you can still salvage my little test template). – Valento ^msg 11:34, 6 July 2015 (UTC)

An example entry for Pyromancer's Puissance:

| relatedskills = Fireball,Lava Font,Flame Burst,Burning Retreat,Meteor Shower,... // goes on, and on, need to account for all weapons

– Valento ^msg 11:37, 6 July 2015 (UTC)

Kind of works... just don't mind the parameter, I put it there because I don't know how to check if there are traits pointing to a certain skill name. – Valento ^msg 13:47, 6 July 2015 (UTC)

• Should include trait description.
• You have to query on {PAGENAME} directly - can't use {name} because that's specifically "for-display-only" when multiple skills have the same name and we have to differentiate the page names. Obviously this means that the values given for {related skills} also have to match the page names.
• Property name bad. Should be a verbal phrase like Relates to skill (and yes, it should also be singular even if it can be multi-valued, because each relationship is still 1-to-1 - read it as A relates to skill B and A relates to skill C etc.).
• Traits that affect categories of skills (e.g. shouts, fire spells, etc.) shouldn't have to list every skill in those categories. Instead, we should continue and expand the scheme used on e.g. Virtue of Justice, where we link to the related traits section of the skill type's page. This will require a separate property, Relates to skill category.
• We also need to cover things that aren't skills (i.e. conditions/boons/CC), but that would likely require different parameters. I'm thinking {applies}, {removes}, and {benefits}... might be more. These would obviously have corresponding properties Applies effect, Removes effect, Benefits from effect...

—Dr Ishmael 15:11, 6 July 2015 (UTC)

Those are quite a few things, and definitely worth going through. I think it's still worth to refactor a "Related trait" template to handle all of those, also, {applies}, {removes}, and {benefits} look too much. Can it just be {affects}? If so, we'd have:

• relatestoskill - Skill list this trait applies to.
• relatestocategory - Categories this trait applies to, has to work out to automatically attach link to skill type page.
• affects - Effects this trait applies to.

I'm still confused how it would look for example for Lava Font. I guess it would just list Persisting Flames, and since it's a fire attunement it would have a small section linking to Fire Attunement-related traits. Persisting Flames would be something like:

• relatestoskill - Lava Font,Flamewall,Burning Retreat
• relatestocategory - Fire Attunement
• affects - Empty

Thoughts? – Valento ^msg 17:27, 6 July 2015 (UTC)

I don't even know how to check if SMW got results, but here's a pseudo-code:

if (smw.traits.relatestoskill($skill)) {

    // Insert "Related traits" section header

    if (smw.traits.relatestocategory($skillcategory)) {

        // Inserts small section linking to $skillcategory

    }

    // Displays each trait with icon, name, and description

}

– Valento ^msg 18:13, 6 July 2015 (UTC)

Effects: With only a single property, there's no way you could split out the "Traits that apply <effect>" / "Traits that remove <effect>" / "Traits that benefit from <effect>" subsections of e.g. Bleeding#Related traits.

Persisting Flames has nothing to do with fire attunement. This is what it should have:

{{#set:
| Relates to skill = Lava Font
| Improves effect = Fire field, Blast finisher
| Applies effect = Fury
}}

Downed needs to be in there somewhere too.

To check presence of related traits, store the query output in a variable so you can check its value and then process it without running the query twice.

{{#vardefine:related_traits|{{#ask:[[Relates to skill::{{PAGENAME}}]]}}}}
{{#if:{{#var:related_traits}}|{{#arraymap:{{#var:related_traits}}|,|@@@|... do stuff with @@@ ...|}}}}

—Dr Ishmael 18:42, 6 July 2015 (UTC)

These are very helpful, thanks! I am also concentrating "applies, removes, benefits" to effects only. I'm adding fire field, blast finishers, fire attunements, to category. How does that sound? – Valento ^msg 18:47, 6 July 2015 (UTC)

No, combo fields/finishers aren't categories, that doesn't make any sense. They are effects caused by a skill/trait just like conditions or boons - the only difference is that they have a physical presence in the game world rather than being an ephemeral "thing" applied to a character.

Fire attunement isn't technically a skill category like signet/shout/etc. that is identified in a skill's tooltip, but it's similar enough that we can treat it that way. —Dr Ishmael 18:58, 6 July 2015 (UTC)

I'm having trouble with page names... I'll try and see if I can find anything later. – Valento ^msg 20:56, 6 July 2015 (UTC)

The properties need to have type page, not text, because they should always match to the name of a wiki article. —Dr Ishmael 12:53, 7 July 2015 (UTC)

Oh, I'll change that now. Btw, how the hell am I supposed to create small specialization sections to group traits? hahah – Valento ^msg 13:09, 7 July 2015 (UTC)

[[Property:Relates to skill|Lol wat?]] – Valento ^msg 13:11, 7 July 2015 (UTC)

About my first point (specialization section to group traits), I could do a big list of #ifs, but I'm not sure if that's the best way to go, it looks to crude and squishy. How'd you go about grouping traits? I know Persisting Flames mentions specifically Lava Font, so I have to display it under a "Fire" section, but there can be multiple specializations. I could #ask by PAGENAME and IsInTraitline, but it would cause a huge list of #ifs to go through, can #ask simplify it? Or is there a better approach? – Valento ^msg 14:11, 7 July 2015 (UTC)

(Reset indent) There are a couple options for that. Actually, before that, there are a few improvements to make:

• I'm a ditz for not thinking of this before. Instead of storing the output in a variable to check for displaying the section header, just use the intro parameter of #ask. {{#ask:...|intro=== Related [[trait]]s ==|...}} (yes, all the equal signs are confusing, but only the first is interpreted as the assignment operator). If #ask returns no results, it doesn't display the intro.
• Since we're getting rid of the variable, there's no need to use #arraymap - just use the template parameter of #ask to process the results directly. You'll have to write a new semantic result template to encapsulate the {trait icon} - {trait description}. (I'd even suggest skipping those template calls and pulling the wikicode from them directly into this new template.)
• Sort the output by sort=Is in trait line,Has canonical name.

Okay, now for the options.

• Switch from headings to displaying the specialization's icon before the trait icon. I think this would be a great way to make use of the spec icons.
• Use tracking variables in the result template to display a header the first time, then skip it for every subsequent appearance of the specialization. The first time the specialization is seen, the variable won't be set, so it uses the given default of 0.

{{#ifeq:{{#var:trait list header <specialization name>|0}}|0|
; [[<specializtion name>]] {{#vardefine:trait list header <specialization name>|1}}
}}

NB: SMW has an 'outline' format which would group them the way we want, but unfortunately it can't apply any templates to the output. I haven't played around with it to see if it would be possible to #arraymap the output, but that could be another option. {{#ask:[[Is for profession::Elementalist]][[Has game context::Trait]][[Has availability::Current]][[:+]]|?Is in trait line|format=outline|outlineproperties=Is in trait line|limit=60}}

Elite Specializations and Proficiency Traits

The <Weapon> Proficiency class features that come along with each elite specialization (for example, Greatsword Proficiency (reaper)) are treated largely like traits, but because this template doesn't have a categorization for them, they can't be categorized properly and don't appear when Template:Trait table is used (as on Reaper and List of necromancer traits. My general thought is to edit this template to include a "Tier 0" trait category simply called "Proficiency" traits, and treat weapon proficiency as a minor trait in that tier, so it could be properly categorized and listed on trait pages for that class and trait line. Unfortunately, I don't know nearly enough of the advanced template coding used to be able to kludge a solution together. Does anyone have the knowledge to do something like this, and is it feasible/worthwhile? Entrea Sumatae [Talk] 20:20, 28 August 2016 (UTC)

These don't have a tier, type, or anything, it's only going to be a generic trait. I'm not sure it's worthwhile to add them to trait tables as users aren't going to find the weapon proficiency trait informational (and probably silly).--Relyk ~ talk < 03:00, 29 August 2016 (UTC)

Profession parameter should be present

In elite spec traits, the icon in the infobox only points to the elite spec itself, not the profession. I think, even for the core traits, it could have a separate parameter which would clearly name the profession they belong to. --Genie (talk) 18:09, 15 July 2023 (UTC)

Rewrite without DPL

Can we attempt a rewrite on the "Improves skill/type/boon/condition/weapon/aura/effect/trait" section please without using #dplreplace?

There is a potential requirement that we'll have to disable the DPL extension for a bit, and I'd prefer not to lose the improves x functionality. -Chieftain Alex 19:33, 1 April 2024 (UTC)