Distribution slider implementation

[marcustyphoon]

Right now, the distribution slider is implemented as a set of values that sum to 100, and the optimizer's calculation output is (pseudocode):

const { powerDistribution, burnDistribution, bleedDistribution, /* etc */ } = distribution;
// burnTick is the calculated damage of one burn tick with current modifiers, etc

const powerDamage = powerDistribution * effectivePower / 1025;
const burnDamage = burnDistribution * burnDuration * burnTick / 131;
const bleedDamage = burnDistribution * burnDuration * burnTick / 22;
// etc

const totalDamage = powerDamage + burnDamage + /* etc */

// contribition to your total damage from power = powerDamage / totalDamage
// contribition to your total damage from burning = burnDamage / totalDamage

What, you may ask, are the magic numbers 1025, 131, and 22? 1025 is the effective power of having no gear, buffs, or traits, 131 is the burn tick no gear, buffs, or traits, et cetera.

This means that, if you ran the optimizer with no traits, buffs, or gear, effectivePower / 1025 = 1, burnDuration * burnTickPerSecond / 131 = 1, etc, and so your damage result would just be the sum of the distribution inputs (which would be 100), and each part would contribute the stated percentage to the total.

This is why I say that, right now, the input percentages represent doing your rotation on a golem naked. If you did that, and put the the distribution into the calculator, it would accurately represent your damage, and as you put your gear back on on both the golem and in the calculator, they would continue to stay in sync.

---

This, of course, doesn't make a ton of sense. No one is fighting the golem naked to get optimizer inputs; we want to get data from golem benchmarks that use meta gear and builds. Further, we want to easily be able to simulate buff effects that do not scale linearly, like geomancy sigil gives me an average of x extra stacks of bleeding.

Here is, thus, what we want in the rewrite:

// all of these values assume you have no modifiers
const { powerCoeffPerSec, burnStacks, bleedStacks, /* etc */ } = distribution;

// burnTick is the calculated damage of one burn tick with current modifiers, etc

const powerDamagePerSec = powerCoeffPerSec * effectivePower;
const burnDamagePerSec = (burnStacks * burnDuration) * burnTick;
const bleedDamagePerSec = (bleedStacks * burnDuration) * burnTick;
// etc

const totalDamagePerSec = powerDamagePerSec + burnDamagePerSec + /* etc */

Why is this good?

• Assuming you use the right method to convert between them, the math is the same as the old way (details below)
• The distribution inputs scale additively with things like on crit sigils that we couldn't previously account for. An air sigil procced every 3.5 seconds is +0.314 powerCoeffPerSec.
• The output is now DPS. This means that, if we correctly hook up templates that input the metabuilds and output the golem DPS exactly when the "golem benchmark" buff preset is selected, you can then say, "how much DPS do I lose if I use scholar rune?" or "how much DPS are infusions?" Snow Crows discord "ask us anything" channel should enjoy that second one.
• We can now easily output e.g. burnStacks * burnDuration = effective burning stacks, which should match the average number of burning stacks in the golem benchmark, and burnDamagePerSec, which should match the DPS contribution from burning in the same way.

---

How do you convert from one to the other? (for testing the new code against the old code)

I actually wrote this post just for myself to understand enough to do this section LUL

new power result = powerCoeffPerSec * effectivePower;
old power result = powerDistribution * effectivePower / 1025;
powerCoeffPerSec * effectivePower = powerDistribution * effectivePower / 1025
powerCoeffPerSec = powerDistribution / 1025

old condi result = burnDistribution * burnDuration * burnTick / 131
new condi result = burnStacks * burnDuration * burnTick
burnStacks * burnDuration * burnTick = burnDistribution * burnDuration * burnTick / 131
burnStacks = burnDistribution / 131

"Just take the inputs from the old optimizer and divide by the magic numbers it uses, then put them in the new optimizer and verify the results are the same." Nice, that's what I thought.