We are excited to announce Path of Exile: Siege of the Atlas in our exclusive livestream on Twitch! Find everything you need to learn about this expansion in this news post.
... Read more
That's really interesting, now you've got me very curious about how that works internally. In my mind modifiers worked by taking an accumulator bucket for additions/subtractions, an accumulator bucket for increases/reductions, and then multiplying them with each more multiplier in order, optimizing to ignore each step if there's no modifiers to them.
You'd end up not having to create an accumulator for increases/reductions, but then have to do a product of a single more multiplier, which I'd have imagined would be easier.
Perhaps my oversimplified assumptions are what makes it different from what's actually been done.
edit: Oh perhaps the more/less modifiers have to be maintained as objects where increases/reductions can simply have its value added to each accumulator bucket that qualifies for its mods and then ignored from then on?
Stats have values, and those values can come from multiple sources. The value of the stat is fundamentally the sum of all the values contributed from things adding that stat - i.e. any given stat is fundamentally additive with itself. This makes sense, if boots give 3 value of something, 3 passives give 2 each, and a buff gives another 1, you expect to have 10 total value of that thing.
As such, only one stat is needed for standard increased/reduced [thing] modifiers, and each thing that needs to increase or reduce [thing] just adds some value component to the [thing] increase/reduce stat (positive for increasing, negative for reducing).
But each multiplicative modifier needs to be it's own separate stat and can't be re-used in any context where something could end up getting the same one from multiple sources, because they would stack incorrectly if that happened. And each of those stats needs to be implemented in the relevant calculation (instead of re-us...
Read moreBy default:
The "can" in those first four means that if the hit tries to apply that ailment, damage of that type is counted for determining how strong the ailment will be (a hit can't inflict an ailment at all if it deals no damage of a type that can inflict it).
The "always" in the second four means the same as having 100% chance to inflict the ailment - the hit will always check how much damage it does of types that can inflict that ailment, and attempt to inflict it (but will fail if it dealt no damage of approriate types, or not enough damage to the point the ailment would be insignificant and is skipped).
You need both things to m...
Read moreHi u/Mark_GGG , I was wondering if "15% more projectile speed" from the projectile mastery work as a more multiper to speed and dmg or is it just a increased multiplier. Appreciate ur works :D
The mastery only affects increases and reductions to projectile speed, not "more" or "less" modifiers.
Yes absolutly ! Ill take my chances : /u/mark_ggg would you be gracious enough to clarify for the sake of the new bow mastery "arrow speed = bow dmg" if projectile speed counts as arrow speed or if you specificly need the stat "arrow" speed to benefit from the mastery ? Thx
The mastery stat in its final version actaully affects increases/reductions to projectile speed. There are very few sources of arrow speed modifiers in 3.17.0, but technically the mastery would work with them, because a modifier to arrow speed is a modifier to projectile speed that is further restricted to only arrows - the mastery makes this apply to damage with bows, but still restricted to only arrows. At least for now is still all damage dealt with bows uses arrows, so this extra restriction doesn't change anything.
please change the "reduce" to "less".
for near all build, it would change nothing, and it would be mush more clear.
It changes a lot internally, adding overhead to the modifier that is unecessary.
Quick question, restoring unconditional rampage doesn't mean the rampage on hit will go away, right?
It will have both