Template talk:Ability infobox

Suggestion
Replace the current block: --><!-

--> With something like this:

}} I have no idea, how you make and parameter in a single if.Prometheus12345 (talk) 09:39, 21 May 2014 (UTC)
 * The previous version had same problem, unless both parameters defined the category name wont be inline with the category scheme you guys set. Unfortunately during my attempt to fix it, I was little preoccupied allowing for a very basic logic error, but its fixed now. Thanks for double checking. --AnotherArk (talk) 10:36, 21 May 2014 (UTC)
 * Thanks. Prometheus12345 (talk) 10:49, 21 May 2014 (UTC)

Links
Why are Linger and Cost shown as links, even though the code is the same as with Duration and Damage?--Lychnidos (talk) 19:26, 6 April 2015 (UTC)
 * The properties weren't defined, but it should be fixed now. --Alianin 00:29, 7 April 2015 (UTC)

type fix
Fixed by removing the part which was supposed to auto-assign type based on class when type wasn't listed, but didn't work and broke chanter in the process (the first of the two possible chanter types was always displayed regardless of the manual value). I'm struggling even with basic wiki formatting let alone advanced markup, so requesting someone more capable to take a look and add back the fixed auto-assign.

5.164.104.94 15:46, 14 May 2017 (UTC)


 * For now, I have undone your last edit. I guess, there will be soon some changes to this template or its use … -- UserCCCSig.png  -- You talkin' to me? -- cCContributions -- 14:10, 30 October 2017 (UTC)

Bracketed values when using this template
Most pages using this template list damage and defence types in double brackets which results in markup being displayed on the page. Any way to make it accept both bracketed and unbracketed values, or have a bot go through them?

5.164.104.94 15:46, 14 May 2017 (UTC)

Notes on infobox conversion
As part of converting this infobox to the new type, I've made some notes, as it's a fairly complex process for this one. We also need a few changes; mostly to field names (need to use underscore instead of spaces, otherwise Cargo won't understand it properly), but we could also use a few extra fields, instead of dealing with it via #switch or similar.

Below are my current notes, which should give an idea for the changes I have in mind.

Learned: possible from? Extra field for Automatic/Optional? Uses: needs source too

--> "..."

first appeared in::Pillars of Eternity     -->

The actual conversion will be carried out by my bot, but most likely I need to manually check all pages afterwards, and make small fixes here and there. We may also have to re-check against the game, to make sure everything is updated with the most recent game version (3.06). I suspect many of these pages have not been maintained, given the lack of consistency in data layout.

—Pangaearocks (talk) 22:29, 31 October 2017 (UTC)


 * I suppose this is meant as room for thoughts and opinions?


 * As this is the first time, the two of us come to an official talk here, I possibly go further into detail than necessary. Let's see …


 * desc > description – I do like more descriptive fields, so one does not always have to look at the documentation when filling them out, but here I deem this redundant; but it's okay, nevertheless, and consistent, I assume …
 * learned – Possibly two fields? learned_level and learned_event (or something similar)? Both optional and depending on the value of the original field.
 * automatic – Allowed: "yes" and "no", which converts to "Automatic" and "Optional". (Rather adverbs? "Automatically" and "Optionally"?) Might be not used often … Would yes=Automatic / no=@hide suffice?
 * accuracy > accuracy_mod – To prevent confusion (see first item).
 * damage, defense, dd, ed, effect – These all should be more descriptive, also on the documentation. To tell the truth – after not having played the game for a couple months, I would have trouble to fill out these fields correctly; even back then I found it difficult …
 * damage – Leave as is.
 * damage_type – Place after damage.
 * effects – Leave as is (+"s").
 * defense > defense_attacked – More clarity.
 * ddefense > defense_damaged – More clarity.
 * edefense > defense_affected – More clarity. Though affect and effect are different things, perhaps this makes it a bit more clear.
 * uses – Why not leave uses and add uses_source?


 * I agree with all other changes.


 * What did you want to say with the last portion, "ingame desc" and "quote" and that?
 * -- UserCCCSig.png  -- You talkin' to me? -- cCContributions -- 12:03, 1 November 2017 (UTC)


 * I misunderstood uses (and confusingly the old infobox used it for different things), but have fixed it in the actual code, so that uses is its own field, and source and source_cost are two others.
 * I'm actually not sure what practical use there is for defense, ddefense and edefense. In the SMW property pages and the template, they basically point to the same thing.
 * Effects is another big problem, I realise, after checking some abilities in the actual game. We'd probably need a crapton of fields with numeric values to catch all the permutations, so it might simply be better to just list more stuff under effects, and not try to divide it up into 20 different fields or so. An ability can have several different effects, with different areas, different accuracy bonuses/penalties, different defence ability (will/deflection/etc), different ranges. It may actually be more confusing to try to divide it up in so many fields, than to more or less list each effect with Wikitext.
 * Whatever we do, we're bound to not pick up all the permutations, so changes will have to be done along the way. But right now I'm leaning more towards putting more 'stuff' into the effects field, at least for the more complex abilities with diverse effects. If we were to divide up a whole heap, it would have to be formatted together again in the actual output, so there really isn't all that much point in creating damage1, damage2, damage3, defence1,defence2, etc etc, ad inf.


 * We seem to basically agree. I'd say about Automatic/Optional that it's probably best to use a string value instead of binary fields, because then it's easier to list it in tables or lists without needing to convert the data first. Probably works better for Drilldown too, though I'm not entirely sure about that. I'll play around some more with it today, get some basic layout code sorted, and take it from there. Whatever is done, every page needs to be checked for quality, as it's clear many of them are outdated, or inserted info in different ways (like damage in the damage field, plus under effect).
 * Pangaearocks (talk) 19:44, 1 November 2017 (UTC)


 * The thing about the three defense parts is this: an ability as attack addresses the target's defense – hit or no hit. If the ability hits, it can do damage to a specific defense, ddefense, or it can "debuff" (from the description)/add an effect to a specific defense, edefense. These small differences might fall into the same category as your thoughts about the effects, though there has to be distinguished between defense and affections.
 * dd and ed have been implemented rather lately, I think. Perhaps that's the reason for a lack of integration into the SMW.
 * And I totally agree: that bunch of different possibilities for an ability's effects is a big downer, regarding table layout, lists, and whatelse …
 * I'm not sure I've understood your "Automatic/Optional-string-binary" thing … And neither that you have understood my "yes=Automatic / no=@hide" thing. What I wanted to say: automatic, yes! Generates "Automatic(ally)" in the infobox and lists/tables if set to "yes", and remains blank if set to "no", instead of "Optional(ly)".


 * I cannot deny that I sometimes have the impression, you're leaving a lot of things out when replying to my questions. Am I asking too many? -- UserCCCSig.png  -- You talkin' to me? -- cCContributions -- 20:39, 1 November 2017 (UTC)