Mark_GGG

You can use those supports with Varunastra. You justcan't use them with skills that have conflicting weapon requirements - Varunastra has nothing to do with that.

Yes.

Technically we didn't showcase it being able to do that, we showed an image of some theoretical possible future ascendancy stuff with no implementation. It had a text descrtiption and nothing else.

Regardless, that doesn't run into the same problem. In that case you're using melee skills with a main-hand weapon, while treating it as a melee weapon type, which is something they already handle.

Bow skills not handling off-hand stuff is entirely different.

That potential future mechanic has some hurdles of it's own, but they aren't nearly as big has making all the code related to and interfacing with bow abilities work with off-hand weapons & animations.

It was broken. Not in the sense of being unbalanced, it caused crashes in serveral cases and incorrect behaviour in a lot more. None of the stuff for bows is set up to happen with the off hand, and this leads to crashes or stats that can't work correctly. Melee and ranged weapons skills have different requirements for animation data for different cases.

The amount of work that would be needed to legitimately allow Varunastra to function as a wand is prohibitive, and as a bow is much more so again.

I'm not sure that it has been clarified but can the player also damage the effigy 'totem' and take their own reflected damage?

No. The Effigy is on the player's team, only enemies can damage it.

None of those affect minions. You minions are not you and do not have your passive tree.

Reflected attack/spell damage can in general be blocked with the appropriate block chance, or evaded/dodged with the appropriate chance. That's been the case for ages.

EDIT: Checking the code, looks like reflected spell damage can be suppressed as well, which makes sense.

All "reduced" (and "increased") modifiers to damage taken stack additively with each other. They apply specifically to damage taken, which is post-mitigation.

the block does not apply here

Also, this is wrong.

PoE does something like that in a general sense, yeah. Objects have a list of buffs/debuffs on them, and each buff/debuff has a variable for time left, and they get iterated to subtract from it each frame. Provided the structures for holding them are fast to iterate and you're not doing much on each other than that subtraction this isn't a huge deal. And it is flexabile - we can have some buffs see time passing at a different rate (such as with Temporal Chains) by manipulating how much frame time you tell each one has passed - but like with effect, we don't calculate that modifier every time, we calculate it when something affecting the result changes and store the result in the buff to be used without needing to recalculate each frame.

Depending on the requirements there might be other options. I'm coming up with this on the spot, but as an example if you're willing to commit to keeping the list ordered by how much time each buff has left, that adds cost to adding new ones...

we know ailments still have values regardless of if you're affected by them or not.

Buffs and Debuffs (including but not limited to ailments) have an internal magnitude for each stat they apply to the thing they're on. This can be thought of as the "base" value for that effect of the buff/debuff. The actual effect of a buff/debuff is adding amounts of stats to a target. The amount of stat a buff/debuff applies is determined by it's magnitude, modified by any modifiers to it's effect. There are several categories of such modifiers:

• The source of the buff can apply "increased"/"reduced" or "more"/"less" modifiers to the effect of the buffs/debuffs they create. In general these are locked in at the time the buff is created, because after being created a buff is independant of it's creator, linked only to its target - the thing the buff/debuff is actually on. So if you chill something, and then gain ...

I mean, "unaffected by chill" doesn't mean "chill effect on you is 0%"

It does mean exactly that.

Is the application of non-damaging aliments (and stuns) effected by the extra life of wellspring of Creation?

Yes. Ailment Threshold (the amount of max life something is treated as having for calculating ailments/stuns) has been calculated separately from actual max life for a while now, and these keystones do apply to both.

Conversion has actually worked this same way with modifiers since closed beta (and before that, only modifiers to the final type applied - physical damage converted to fire wouldn't benefit from physical damage modifiers, only fire). There has never been a case where conversion caused a modifier to elemental damage to apply multiple times to the same damage.

I'm not really sure, sorry. I would have to go digging through the revision history, and I don't have time for that. I think the change from boolean to less was in the same patch as the flask, but not 100% sure.

No, we've come full circle on that.

Freeze was originally 100% reduced action speed (back in the day there were no more/less modifiers. It was a simpler time). And that was fine, because that would always fully stop things.

Then at some point we added something that could increase action speed, and it was no longer fine, because that let things move while frozen, which was unintended. So freeze changed to a magnitude of something like 200% reduced action speed, which solved the problem temporarily, but was never going to work long term.

Eventually as action speed modifiers became more complicated, freeze was changed to have a boolean effect which set action speed to 0, ignoring (most) other modifiers. As a boolean thing, this couldn't be scaled, which was fine, because freeze wasn't a thing that could be scaled anyway.

Some bosses got various forms of "action speed cannot be modified below X", shown as "cannot be fully slowed", which freeze did respe...

have you played a freeze build?

I implemented a freeze calculation function, so I figure that's close enough.

Freeze always has a base magnitude of 100% less reduced action speed. Effect modifiers modify that value.

Damage does not affect freeze magnitude like it does for other ailments, it affects duration instead.

The only requirement to be able to freeze is that freeze duration is at least 0.3 seconds. This requires dealing a certain amount of damage, since that is what determines base freeze duration, but modifiers increasing the duraiton of freeze make it easier to reach that minimum.

Modifiers to effect don't help meet the minimum duration, because they change effect, not duration.

EDIT: I see from other posts the source of confusion may have been found in Bonechill, which makes enemies take increased damage based on the effect of chill on them. This means modifiers that boo...

Technically yes in that it can also help partially counter "less" modifiers* to the effect, not just "reduced".

It does not affect duration of the freeze in any way, and thus cannot help a freeze meet the minimum duration to be applied. Duration and effect are different things.

*So long as the less modifier has a value lower than 100%

Exactly the same kind that has existed since closed beta to prevent the additional life monsters get from party size affecting detonate dead.

To be specific, Detonate Dead already uses "intermediary maximum life", which is a separate stat calculated from the base and applying most but not all modifiers. Further modifiers are applied to that stat to get actual max life used for the amount of life stuff has.

Path of Exile isn't isometric, it uses perspective projection - stuff further from the camera looks smaller.

1) That would be a much less clean way to implement Varunastra than the current way, because that would require substantial redefinition of what weapon base types are that would affect all weapons.

2) That would not solve this issue, because this issue is not actually about Varunastra, which was the main point of my post.