Module:AbilityTable/Lists/doc: Difference between revisions

No edit summary
Vergir (talk | contribs)
Document Key:Value and dot-path target forms (with help from vergir-bot LLM)
Line 1: Line 1:
== How targets are matched ==
Every entry in a list is a ''target'': a string matched against each ability record in [[Data:AbilityData.json]]. There are four forms.
{| class="wikitable"
! Form !! Example !! Matches when
|-
| Plain name
| <code>SilenceDuration</code>, <code>Card Trick</code>
| a property with that name exists anywhere in the record and holds a non-zero, non-empty value, ''or'' the string appears as a value anywhere in the record. Raw ability names work because the ability's <code>Name</code> is such a value.
|-
| Name with a value
| <code>Type:spirit</code>
| a property with that name exists anywhere in the record and its own value is <code>spirit</code>
|-
| Nested path
| <code>AbilityDuration.Scale.Type</code>
| that exact chain of properties exists and ends in a non-zero, non-empty value
|-
| Nested path with a value
| <code>Scale.Type:cooldown</code>
| that chain exists and ends in <code>cooldown</code>
|}
A few details worth knowing:
* '''Values are compared case-insensitively.''' <code>Type:spirit</code> and <code>Type:SPIRIT</code> select the same abilities.
* '''A property's value is its own value, not anything nested inside it.''' Damage is stored as <code>{ "Value": 90, "Scale": { "Type": "spirit" } }</code>, so <code>Damage:90</code> matches it but <code>Damage:spirit</code> does not, the <code>spirit</code> sits on a different property. Use <code>Damage.Scale.Type:spirit</code> for that.
* '''Only the first segment of a path is searched for.''' It is found at any depth, and the remaining segments are then followed one step at a time. This is what lets a path reach into sub-ability records.
* '''Paths step through lists.''' <code>Upgrades.Damage</code> matches if ''any'' upgrade has a Damage value; <code>Upgrades.1.Damage</code> checks only the first upgrade.
* A target containing a dot that doesn't resolve to a path falls back to plain matching, so a value that happens to contain a dot still works as a target.
== How to add a missing ability to a list ==
== How to add a missing ability to a list ==


Line 6: Line 39:


'''Finding the right property''': Open [[Data:AbilityData.json]] and search for the ability. Look through its properties for one that represents the relevant mechanic, for example, a silence ability might have <code>SilenceDuration</code>. A good property is one shared by many abilities with the same mechanic, not something unique to one ability.
'''Finding the right property''': Open [[Data:AbilityData.json]] and search for the ability. Look through its properties for one that represents the relevant mechanic, for example, a silence ability might have <code>SilenceDuration</code>. A good property is one shared by many abilities with the same mechanic, not something unique to one ability.
If a property is shared by many abilities but only some of them have the value you care about, use the <code>Key:Value</code> form to narrow it down. Ability scaling is the usual case: nearly every ability has a <code>Scale</code>, so <code>Scale.Type:cooldown</code> is what separates the ones that scale with [[Ability Cooldown]] from the rest.


After adding the property or ability name, test the table to make sure no unwanted extra abilities appeared. If they did, the property is too broad, consider using a raw ability name instead, or adding the extras to <code>exclude_abilities</code>.
After adding the property or ability name, test the table to make sure no unwanted extra abilities appeared. If they did, the property is too broad, consider using a raw ability name instead, or adding the extras to <code>exclude_abilities</code>.