Quote
Perhaps this is a better explanation: Wereform paw attacks are NOT borrowing the frame data from the human form animations. Rather a slowing factor is being applied to the traditional wereform animations so that the overall duration comes out the same as the human animation. (Though some breakpoints may be 1 EIAS off due to rounding issues.)
So all of the werewolf paw attacks use the traditional actionframe = 7, framesperdirection =13, animationspeed = 256. And there werebear paw attacks use actionframe = 7, framesperdirection =12, animationspeed = 224. Use those, not the human form values. Now, after we get to the step where we compute increment = TruncateToInt((animationspeed * cappedeias)/100) we now have an extra step were we apply the slowing factor: increment = TruncateToInt(increment * wereformnerffactor). And what's wereformnerffactor? It's (wereformframesperdirection * humananimationspeed)/(humanframesperdirection * wereformanimationspeed).
Quote
(To account for werebear and sorcs and amazons and claws, it's probably really more like (wereform_framesperdirection * human_animationrate)/((human_framesperdirection - human_startframes) * wereform_animationrate), but let's get werewolf solved first.)
Quote
New update. I went with Truncate((Truncate((256*werewolf_framesperdirection)/human_framesperdirection)*(EIASplus100))/100) in this version since that matches more of the troublesome breakpoints than any other option right now.
Quote
There is only one thing I can think of. It's ugly. I hate it. It's so unnecessarily complex I don't see how a programmer could plausibly write it. And it has some really, really bad implications for how it would complicate gear selection. But it matches the data points, and it's all I've got:
If we pull apart the terms composing EIAS, one of them is negative for the first data point (the "minus WSM" term). So we do TruncateToInt((animation_speed * EIAS_component * werewolf_framesperdirection)/(100 * human_framesperdirection)) and then repeat for each component of EIAS, and then sum them. If we assume truncation means "round towards zero" (see the comments in math.js about this), then one of the truncates is a ceiling() for the first data point but a floor() for the second data point. Aha! Different rules!
Tentatively, I broke EIAS into minusWSM, skill_and_gear_EIAS, and constant100 and ran the three problem breakpoints on a pocket calculator. They each came out correctly. I'll need to refactor the javascript calculator to try handling EIAS in this crazy way so we can see if it messes up any of the other tested breakpoints. The division of the positive terms into skill_and_gear_EIAS and constant100 was an arbitrary guess on my part. Figuring out which division of the positive terms (if any of them!) is correct will be a pain.
(Again, I really, really don't like this idea; I just don't have a better one.)
Quote
EIAS = skill_IAS + DiminishingReturns(gear_IAS) - WSM
base = animationspeed
delta = TruncateToInt((animationspeed * EIAS)/100)
increment = base + delta
increment = TruncateToInt(increment * nerf_factor)
I'll have a look on this in excel and see if i can fix my excel sheet.
This post was edited by gel87 on Apr 25 2022 01:40am