Talk:List of traits

It's neccesary with the list being mentioned and extended on trait? Lokheit 22:00, 13 June 2011 (UTC)

I never said it was necessary, but consistent. - Infinite - talk 11:02, 14 June 2011 (UTC)

New organization style

Figure I'd put this here since it applies to all list of traits, but with the new tier system what if, for functional gameplay purposes we started putting the traits in this order:

• adept traits

• minor
• majors

• expert traits

• minor
• majors

• grandmaster traits

• minor
• majors

This would list the bonuses in the order that they become unlocked and would be useful for people trying to buildcraft because you can scan down the list and say "well this is worth investing trait points in, how abou the next trait?" If no one objects I will implement the changes as soon as I figure out how to edit wiki code tables --Indigo121 17:59, 22 June 2012 (UTC)

Good idea. (1) Try this in your Sandbox first, so people can offer suggestions before overhauling the page. (2) Please list the majors in alphabetical order (within their section). – Tennessee Ernie Ford (TEF) 18:19, 22 June 2012 (UTC)

Thank you TEF. I set up the table as best I could figure out how for now, I'll add the descriptions in a few hours when I can do things from my computer instead of my mobile phone. Meanwhile, if anyone wants to add the polish or descriptions feel free to go ahead and do so. I think the structure works fairly well, and has some good utility to it. --Indigo121 23:09, 22 June 2012 (UTC)

If we're rearranging these tables, can we please do away with the rowspans? Here's my idea - since there's exactly 1 minor trait per tier, we can simply apply special formatting to that trait so it stands out, and there's no need to list minor/major in the table at all. The table is reduced to Trait || Description, and I think we don't even need a standard table header for that. —Dr Ishmael 00:34, 23 June 2012 (UTC)

The wiki shouldn't require any special knowledge to read. Different formatting for minor traits without explicitly stating what type they are is not a good idea. Aqua (talk) 00:41, 23 June 2012 (UTC)

I knew someone was going to bring that up. So what? We include a note explaining it. Lots of specialized data representations require explanations of how to read them. I think this one minor thing is a worthwhile sacrifice for a table that is otherwise extremely simple to read. —Dr Ishmael 01:09, 23 June 2012 (UTC)

I agree with aqua in that we ought to distinguish the minor trait in some obvious way, but I do like the simplicity of your design. The idea behind the wiki is to be as clear and informative as possible in my experience, and we all know how infrequently people actually read notes --Indigo121 01:12, 23 June 2012 (UTC)

I added a second trait line to my example with a different idea for the minor trait. Oh, and before Infinite pops in, any final implementation would of course have standardized table and column widths, I'm just feeling lazy about that right now. :P —Dr Ishmael 01:19, 23 June 2012 (UTC)

That's much better IMHO. And while we're on the topic of things that would be corrected in the final implementation, the color of the adept bar is a different shade than the master and grandmaster bars. Not a huge deal, but I like the polish we general have. --Indigo121 01:56, 23 June 2012 (UTC)

I like Ish's suggestion the most (Indigo's also works, but the Doc's is more polished). I agree with a small bit of highlighting on the minor skill with a footnote pointing out it's inclusion is automatic after spending the required pts. (We also don't need to explicitly type out "Grandmaster <br />(Requires spending 30 trait points)" on every trait page.)– Tennessee Ernie Ford (TEF) 02:02, 23 June 2012 (UTC)

The entire table formatting is based on the new CSS classes that were recently implemented. The default is for header cells in the first row to have special formatting, with header cells in other rows having lesser formatting. I've set up the two examples with two different workarounds - the first one is the "clean" method and applies the main header format to all 3 sub-headers. The second is the "hacky" method and forces the first header to use sub-header formatting. —Dr Ishmael 02:25, 23 June 2012 (UTC)

Of the two I prefer my own, but would not be disappointed with either, both are vastly superior to the current model, which wasn't built for the tier system. Mine is admittedly a little less polished but that's largely due to my literacy rate with wiki code --Indigo121 11:48, 23 June 2012 (UTC)

I prefer Indigo's layout to be honest. It's just easier to decipher at a glance. ~ ♥ Kailani! ʕ •ᴥ•ʔ 13:17, 23 June 2012 (UTC)

I've added a bit of polish to mine, been searching out the wiki code to do so, if anyone knows the code necessary to make those background colors look a little better feel free to fix them as you please but I'd say its starting to look quite decent --Indigo121 16:49, 23 June 2012 (UTC)

I prefer Indigo's layout as well 98.70.143.175 01:07, 25 June 2012 (UTC)

(Reset indent) I'm sorry, but rowspan headers are simply a Bad Thing, from the standpoints of both coding and design. For coding, they make static tables extremely difficult to edit, and they make automated tables extremely difficult to program. For design, they clutter up the left side of the table and are an unnecessary waste of horizontal space. They should be converted either to standard wiki headings, which help to break up the data into easily digestible chunks and provide structure to the overall article via the ToC, or to colspanned headers that provide a more obvious split between the different groups of rows.

I've been tolerant of the existing table designs, but now that we have a chance to redesign the trait tables, I am going to fight as hard as I can to eliminate rowspans from them. —Dr Ishmael 02:44, 25 June 2012 (UTC)

I prefer Ish's version primarily because it doesn't repeat redundant details and it's easier to review at a glance: (1) there's only one minor trait per tier; there's no reason to have a column to distinguish major from minor. (2) the nested columns make comparisons more difficult; they force they eye to go back/forth to make sure one is looking at a GM row vs a Master's row. Of Ish's two versions, I prefer the second. – Tennessee Ernie Ford (TEF) 07:33, 25 June 2012 (UTC)

Minor traits are something akin to GW1 attributes with inherent effect, like Death Magic or Dagger Mastery. People will memorize them, and they can be viewed in game at any time. So no, I don't think there's need for trait type column to differentiate minor and major traits, either. I think that the numbered icons for each major trait (like File:Trait_I.png) should be displayed alongside each major trait, though. Mediggo 07:55, 25 June 2012 (UTC)

I still would argue that for the purposes of buildcraft, which is the primary reason people will be looking at trait tables, mine is a little easier to use, as your eyes don't have to stop for the arbitrary names of Grandmaster and Master. I have an idea to incorporate your suggestions Mediggo, I'll put it up in a few minutes so check back on it then. --Indigo121 10:22, 25 June 2012 (UTC)

The tier names are definitely not arbitrary, because in order to use the Grandmaster Major traits, you have to invest a full 30 points into that trait line, or 20 points to use Master Majors, which is pretty darn important for buildcrafting - not everyone is going to use a 30/30/10 trait split. —Dr Ishmael 12:41, 25 June 2012 (UTC)

@Mediggo: I updated mine with icons (and went ahead and added consistent widths at the same time). I also modified {{Trait infobox}} to translate the icon name into a sortkey for the tier categories in order to display the traits in order on the trait table. It'll probably take another 10-15 minutes for that change to finish propagating to all the traits. —Dr Ishmael 13:16, 25 June 2012 (UTC)

I have an idea. How about we add a little marker/tag to every trait in the table, which tells the amount of points you have to spend to gain it. For example: "(20+) Hidden Killer" or "(25) Fluid Strikes". Gnarf 12:55, 25 June 2012 (UTC)

I meant arbitrary in the sense that you just as easily call them red blue and green. The idea of seeing a line break meaning another 5 points for this one is still the same. I personally find it easier to read mine --Indigo121 13:09, 25 June 2012 (UTC)

One thing I like about the rowspan version is that it makes the table more two-dimensional, which flows better for me. I do think that eliminating a column for major/minor would be good. --JonTheMon 13:31, 25 June 2012 (UTC)

What do you guys think though of replacing that column with the number column? I admit it's quite possible those numbers are placeholders until they design actual icons, but if they aren't it is kind of useful info to have right?--Indigo121 13:36, 25 June 2012 (UTC)

Bumping this, we really need to make a decision, the old tables are woefully inaccurate --Indigo121 04:18, 13 July 2012 (UTC)