Template talk:Infobox ability poe2

Updating the ability infobox for Deadfire
Alright, figured we should have a dedicated talk page for this discussion. I've done a quick pass of the fields here, have added some notes for their relevancy in poe2, as well as some general information about what they are and where they come from.

Replies should go directly below (above the line) with suggestions, ideas, opinions, etc. Macklin (talk) 18:36, 17 April 2020 (UTC)


 * This is an amazing piece of work! I've looked over some of it, but I'm sure you have a better idea of what is sensible here, so I trust your decisions. The only comment I have is about this:
 * ability_range -> range
 * Perhaps my memory is fuzzy now, but I thought "range" was a protected word in Cargo. I know they introduced many protected words after I made some of the infoboxes, which broke them and resulted in error messages. If range is one of them, we can't use it. Pangaearocks (talk) 17:50, 19 April 2020 (UTC)


 * You're right about that. The infobox parameter can still be "range", but the cargo_store and cargo_declare sections need to remap it to a different name. Maybe doing so is just confusing, but that seems to be the norm for the other poe2 templates.


 * I've finished writing a parser, now I'm deciding on which abilities to keep and which to omit. Obviously all class abilities are going to be kept. Item/equipment enchantments that use the ability system to grant complex effects won't be included (they're mostly already covered in Template:Infobox enchantment), with the exception of items that grant abilities that can be used by the wielder.


 * Some abilities are duplicates, for example Wizard spells that are granted to non-Wizards as a part of a sub-class or multiclass, abilities with slightly different effects if the player is a certain subclass, abilities granted to creatures and are slightly nerfed. I don't think these abilities are important enough to warrant a separate page. Doing so would be a huge waste of space, and the disambiguations would get messy quick. A "variants" section on the page could be a good solution, describing who the variant affects and what changes it brings. Building this into the infobox for every single field that could be different is overkill.


 * NPC/creature abilities are where I'm undecided. About 25% of creature abilities are copies of class abilities, with minor stat changes. The other 75% are unique abilities, however a good portion of them clearly weren't meant to be viewed by the player as they're missing descriptions/names, etc. To cut down on these, maybe we should only include the abilities that are present in the bestiary entry for the creature. They also have to be marked as such. The ability_type field currently uses "Item" to designate abilities that are granted from items, so perhaps we can also use "Creature" for abilities on creatures. Although we should probably move these to a different field to describe where an ability comes from or originates like "ability_origin".


 * I'll be adding this field, as well as the fields,  ,  ,  . Macklin (talk) 08:56, 21 April 2020 (UTC)


 * Here's the finished extractor + infobox builder: https://github.com/macklinb/DeadfireAbilityExtractor


 * It's super single-purpose, and I don't expect it to be used by anyone other than myself, so I won't bother getting into the details. Even undocumented, perhaps some of this work could be useful to future enterprising wiki-goers.


 * One of the things I had it automate was the creation of icons from File:Poe2 SpellAbilityIcons.png given icon rects, the result of which is already uploaded to the wiki.


 * Currently I'm going though the 1000+ abilities I've serialized, cleaning up edge cases and adding notes to each of the created wiki pages individually. I expect to be feeding it to AWB within the next month after a final once-over. Macklin (talk) 21:04, 18 May 2020 (UTC)


 * All abilities have been added! Some notes about what I've chosen to omit and keep:
 * Omitted abilities granted by items that have the same name and effects as existing abilities. For these, the associated item will be added to rel_items and optionally have their own subheader describing any additional trigger conditions, if any (which are already covered on the enchantment page).
 * Kept subclass abilities that grant abilities from another class. While some of these have different effects, most are identical. I've decided to keep them to not selectively include some of these abilities and not others, adding a disambiguation where needed (e.g. "(Priest of Wael)"). I've also added a variants table to the original ability, which may prove to be enough info than having a dedicated page.
 * I'm yet to add Creature-specific abilities. This is something that I will do at a later point.
 * What's next?
 * The new ability pages need to be integrated into the class pages to provide a list of abilities granted to each class (might just modify the existing cargo template).
 * The class pages also need to be modified to mention poe2 power pool and accrued resources (along with more specific class poe2 info).
 * Links to poe1 abilities on poe2 pages need to be modified to point to the poe2 counterpart. This includes some links on the new poe2 abilities pages (I realized this after I had started creating the pages).
 * The cargo table for Template:Infobox ability poe2 needs to be made (probably after all the links are updated)
 * Template:Infobox ability poe2 needs an equivalent of Template:Cargo wizard spell grimoires
 * I need to make documentation for Template:Infobox ability poe2 using info from this page.
 * Other stuff I don't remember at the moment
 * Macklin (talk) 07:28, 15 June 2020 (UTC)

What to include? What is an "ability"?
Deadfire uses the concept of abilities for almost everything. A majority of these "abilities" are hidden and are a result of enchantments, enemy attacks, consumables, etc. Naturally when a player thinks of an ability, they think of something their character can cast - so we'll only want to include those that are "usable" by the player or party. Unfortunately the game files don't make this distinction very clear, but for a start we can refer to the default progression tables, which are a set of rules that govern which abilities are given to the character.

After this, we have a few more options to narrow down player-only abilities:
 * Remove abilities that aren't shown in UI (where the HideFromUI field is true).
 * Remove abilities that don't have a description or display name

Even then, we'll still be left with a large number of enchantment abilities - for example Missile Cache is an enchantment (ability) that grants a set amount of charges of the actual ability "Minoletta's Bounding Missles". At the moment my inclination is that the remaining abilities will need to be examined manually to determine if they should be added as a page or not.

Types to consider

All abilities are stored in abilities.gamedatabundle (one for each expansion). The game data here only specifies the most-derived class, so we have to determine what should be used from the derivatives of the following classes. Alternatively we can use all gamedata containing a GenericAbilityComponent or PhraseComponent

↳ ProgressionUnlockableGameData
 * ↳ PhraseGameData (Phrases)
 * ↳ GenericTalentGameData (unused)
 * ↳ GenericAbilityGameData (covers most abilities)

Derivatives of GenericAbilityGameData. These only exist to provide additional fields.


 * ↳ AttackLowestDefenseAbilityGameData
 * ↳ AuraAbilityGameData (Auras)
 * ↳ CoordinatedPositioningAbilityGameData (rogue's Coordinated Positioning)
 * ↳ DeathblowsGameData (rogue's Deathblows)
 * ↳ FinishingBlowAbilityGameData (rogue's Finishing Blow)
 * ↳ FocusTraitGameData (cipher abilities that use focus)
 * ↳ LinkedEffectAbilityGameData (only for a cipher's Defensive Mindweb)
 * ↳ MirrorAbilityGameData (wizard's Mirrored Image, and others)
 * ↳ SharedTargetAbilityGameData
 * ↳ SpecialGenericAbilityGameData
 * ↳ WeaponAttackAbilityGameData
 * ↳ WoundsTraitAbilityGameData (monk Wounds abilities)

Unused derivatives of GenericAbilityGameData
 * ↳ BackStabAbilityGameData (unused)
 * ↳ BloodlustAbilityGameData (unused)
 * ↳ ChantGameData (chants are editable and shouldn't be considered as abilities)
 * ↳ DrainingTouchAbilityGameData (unused)
 * ↳ EnervatingBlowsAbilityGameData (unused)
 * ↳ FlankingAbilityGameData (unused)
 * ↳ GenericAbilityWithExtraAttackOnMissAndEndGameData (unused)
 * ↳ GenericAbilityWithPrimaryAttackOverridesGameData (unused)
 * ↳ HeartOfFuryAbilityGameData (unused)
 * ↳ MinorBlightsAbilityGameData (unused)
 * ↳ OneStandsAloneAbilityGameData (unused)
 * ↳ PowderBurnsAbilityGameData (unused)
 * ↳ RighteousSoulAbilityGameData (unused)
 * ↳ RiposteAbilityGameData (unused)
 * ↳ SafeguardAbilityGameData (unused)
 * ↳ SoulMirrorAbilityGameData (unused)
 * ↳ TriggeredImmunityAbilityGameData (unused)
 * ↳ VengefulDefeatAbilityGameData (unused)
 * ↳ WeaponFocusAbilityGameData (unused)
 * ↳ WeaponSpecializationGameData (unused)
 * ↳ WeaponTypeSpecializationGameData (unused)

Some notes about talents, or at least what I can deduce:
 * Talents
 * A talent is any ability (usually passive) granted from being a certain subclass/race/subrace etc, or one that is granted through gameplay (e.g. NPC training, boons).
 * They usually provide permanent buffs or effects.
 * Unlike abilities, talents do not (always) appear in the ability hotbar, and will only appear in the "Current effects" section of the character sheet.
 * Many of these are listed in the "Permanent bonuses" section of Status effects (Deadfire).
 * Typically have an AbilityLearnLevel of 0 or 1 (but this isn't always the case)
 * The game doesn't actively use the word "talent" in-game - only passives or effects.

I think that the distinction of "talent" as a separate table is somewhat unnecessary. There are way too many abilities that can be classed as talents and talents that can be classed as abilities. They use a subset of the fields used for abilities, but do not add any more. We should list all talents in the abilities table and mark them as such with the ability_type field, as all talents are functionally abilities. This is something that is certainly open for discussion. See ability_type below for more.

Fields
Summary
 * Added:
 * subclass
 * learn_level_mc
 * learn_req
 * ability_origin
 * modal_group
 * upgrades_from
 * upgrades_to
 * keywords
 * counters
 * cast_time
 * recovery_time
 * noise_use
 * noise_impact
 * target
 * target_x + effects_x
 * label_x + data_x
 * rel_quests
 * rel_characters
 * guid
 * Removed:
 * speed (substituted with cast_time and recovery_time)
 * talents
 * learn_buycost (not used in poe2)
 * inventor (kind of redundant if it's in the title)
 * Renamed for consistency with other poe2 infoboxes:
 * ability_range -> range
 * area -> area_of_effect
 * abilities -> rel_abilities
 * items -> rel_items
 * Merged into effects, or can be represented using label+data fields:
 * To avoid duplicating fields and to provide less restrictions, most of the attack-related data should be moved to the effects field. Using dedicated fields will get messy since the ability can have multiple durations, defenses, targets, etc. The in-game text should be copied verbatim.
 * accuracy_mod
 * penetration
 * interrupt
 * defense
 * defense_damage (unused)
 * defense_effect (unused)
 * damage
 * damage_type