How ability descriptions work

An ability’s description in the game files contains no numbers. It contains references into the ability tree, which the client resolves as it draws the tooltip.

Blade Cyclone’s reads:

Spin in the targeted direction, dealing
$$SWORD_SPIN_DAMAGE_NOSTACK.directattributechange[0].change$ physical damage
up to $pulsingspell[0].count$ times …

$path$ reads the ability itself; $$OTHER.path$ reads another one. A path walks the file tree, so the 40 damage lives on a helper entry the player never sees.

Two formats, not one

Two thirds of abilities write their references inline like that. The remaining third ship the sentence with {0}, {1} already in it and list the references separately under locareferences. Both are in use and neither is a fallback for the other.

Conventions the paths assume

• A step landing on a list means its first entry.
• channeling is the description’s name for the channelingspell node.
• Container nodes are skipped: spelleffectarea[0].node[0] really means spelleffectarea.area.shape.node.
• Geometry is a range packed into one attribute. @radius="0-3" is read as radius_start and radius_end.
• Some fields are computed rather than stored: total damage over time is change × count, a duration is interval × count.

When a number is a percentage

A value is a fraction of whatever its node modifies, and the files say so five different ways: the node names a stat (@type) or a gathering buff (@bufftype); the node’s own name ends in bonus or contains percent; @changetype starts with relative; @relative on a cooldown reset or @energyusageisrelative on a cost; or the field name says it outright. So physicalarmor 0.22 on a buff is +22% resistances, not +0.22 armor.

Gaps

About 113 numbers across 70 abilities cannot be resolved and show as ?, mostly charge-dependent damage tables, and a handful of references to entries the files do not contain. A gap is left visible on purpose; an invented number would be worse.