Mark_GGG

Additional sources of "reduced -x- damage taken" are applied additively to the effect of Armour.

Not quite - you are confusing "[type] Damage Reduction" with "reduced [type] Damage taken" (which you had already correctly stated applies after armour, as a modifier to damage taken).

Armour applies "Damage Reduction" to the damage types it mitigates - usually this is physical, so "Physical Damage Reduction" Other sources of additional "Physical Damage Reduction" are additive with the Physical Damage Reduction calculated from armour. I don't believe there are currently any modifiers granting "additional [type] Damage Reduction" for types other than physical, but they would add to any damage reduction to that type provided by armour (if any - or add to 0 if armour doesn't apply to that type). Armour doesn't mitigate damage over time, but "Damage Reduction" does, so sources of additional Physical Damage Reduction mitigate physical damage over t...

You cannot, but not because they're exclusive, because suppression happens fist.

Damage is suppressed, then stun is calculated, then the remaining damage can be blocked (fully, or partially with something like Glancing Blows)

Note that armor uses the initial_hit, not the mitigated_hit.

This is not true and never has been. Any other form of mitigation, such as resistances, that's applied before armour will change how armour interacts with that damage. It does not use the "initial" or unmitigated damage for calculating physical damage reduction.

Often nothing else will mitigate physical damage before armour, so this makes no difference, but it absolutely does not look at some "initial" value that can be different from the value with previous mitigation factored in.

Suppressing damage, however, happens after armour because it's a modifier to damage taken.

░░░░░░░░▄▄▄▀▀▀▄▄███▄░░░░░░░░░░░░░░░░░░

░░░░░▄▀▀░░░░░░░▐░▀██▌░░░░░░░░░░░░░░░░░

░░░▄▀░░░░▄▄███░▌▀▀░▀█░░░░░░░░░░░░░░░░░

░░▄█░░▄▀▀▒▒▒▒▒▄▐░░░░█▌░░░░░░░░░░░░░░░░

░▐█▀▄▀▄▄▄▄▀▀▀▀▌░░░░░▐█▄░░░░░░░░░░░░░░░

░▌▄▄▀▀░░░░░░░░▌░░░░▄███████▄░░░░░░░░░░

░░░░░░░░░░░░░▐░░░░▐███████████▄░░░░░░░

░░░░░le░░░░░░░▐░░░░▐█████████████▄░░░░

░░░░toucan░░░░░░▀▄░░░▐██████████████▄░

░░░░░░has░░░░░░░░▀▄▄████████████████▄░

░░░░░arrived░░░░░░░░░░░░█▀██████░░░░░░

You are correct - with CI, your maximum life is 1, so unless you raise your maximum recovery per life leech a lot, it will be lower than one and round to zero.

The stats started applying when you equipped that flask, and were removed when you removed any flask (because items being equiped and granting stats is fundamentally is built around single-item slots).

Any change to an item technically removes and replaces it (this has since changed, so that changing only the number of charges a flask has doesn't require an internal remove/replace), so this was inconsistent, and you'd gain and lose the stats based on which flasks you used.

Think of it this way: you are not attacking 3 times. You are attacking once, with 2 copies.

With Multistrike, your 3 attacks would hit 9 times. Ruthless would be applied to the 7th, 8th, and 9th hit.

This is pretty much correct.

When supported by Multistrike Support, Ruthless blows work differently, instead of occurring every third hit, it occurs every third multistrike.

This quoted part is technically incorrect, in that nothing about how Ruthless Blows work is actually different with Multistrike to without. They are simply completely different effects which care about fundamentally different things - and neither of them care about a number of hits.

Ruthless explicitly tracks how many times you use the skill. When you push the button (or leave it held when finishing the previous skill use) and pay the cost of the skill to start doing it,...

As suggested in this very post, "your overkill damage" instead of "the overkill damage" would make it clear on a careful reading and add zero confusion.

That would absolutely add confusion for some players.

"While you have this buff, if you kill an enemy, other enemies near them will be burned based on your overkill damage."

"your" is really awkward there, and makes the "your overkill damage" part sound like some keyword phrase which is a property of the player character rather than part of the killing event. It feels weird to specify the overkill damage is "yours" there, and not entirely intuitive that overkill damage conceptualy is "yours" when it's fundamentally defined more by the enemy it's happening to than you being what dealt it.

That doesn't mean the current wording is perfect or no improvements are possible, but they have to be carefully considered, and the text is serving it's...

Herald of Ash requires you deal a killing blow, not just kill. This isn't stated explicitly because it's implicit in the fact that it requires overkill damage, which is only possible from a killing blow, and stating it explicitly would make Herald of Ash awkward to read in a way that could add to confusion. This might get re-examined at some point, but care would have to be taken not to sacrifice clarity for new players reading Herald of Ash and trying to understand just that skill, to aid clarity around a specific very niche interaction with a unique item most players will never see.

No, it would need to force a crit, not rely on the chance - the crit roll for that damage is zero.

This actually means it will always crit in this case, which is not intended, and it will be changed to make a crit roll such that it can interact with stuff adding a crit chance in an intuitive and sensible way in future.

You have definitely misunderstood something, as what you are claiming is incorrect.

The system by which the modifications to the tree are determined by the seed has intentionally not been changed since it was introduced, so that the items can continue to function the same way. The Historic jewels actually even have an internal "version" value which was included so that if we ever needed to make such changes, we could have them only apply to new gems and distinguish them in some way by describing the version stat, but we haven't had to actually use that so far.

As noted above, changes to the tree do change the results (and some potential changes to the tree might not be obvious or visible to players, but those would be rare), because the passive skills themselves are inherently one of the inputs. But outside of that, the results of a historic jewel don't change unless it's seed does.

In fact there's a minor bug in the code for making those modifications which...

Maybe /u/Mark_GGG can answer this: Is the explosion caused by the fuse debuff of exploding arrow counted as a hit by the player

Yes

If the answer is "player", is this because a debuff is not an entity that can be assigned a hit?

Not really - a debuff is fundamentally not a game object and can't hit things, but even if it could that wouldn't be what's happening here. The damage is directly caused by your skill which you used.

Conversion from skills has priority - this includes both skill and support gems. Otherwise this is correct.

The only distinction is between conversion from the skill vs conversion that's from the player/monster who's skill it is.

In contrast, trying to dash and simply dashing back to your original position both doesn’t make sense from a mechanical point of view

What's actually happening in these is the target location didn't change, and it was close enough that you've moved past it, so targeting the same location with the repeat causes you to go backwards. However, while it's not how skills actually work, I think there is merit to trying to treat this as though targeting a direction rather than a location, and maintaining that - I've raised this with a designer for further consideration in future.

Yes, any mod. I believe eaten souls are always tied to a specific instance of soul eater, so this would mean stealing a new instance of soul eater would remove all souls you ate with the previous one, but I don't have time to specifically test that and it's been a while since I had to code anything related to soul eater, so my memory may not be completely accurate on that interaction.

Effectively each instance of Soul Eater has a separate soul stomach, and souls can only be put in one of them.

That's not my call to make and I have no idea what plans there might be on that front.

My entirely personal opinion, not reflecting any official GGG position, is that as the person who originally came up with and implemented Headhunter, I hope those continue to occur and cause issues for some players. The fact that some mods could be negative for the player was one of the core things that was cool and interesting about the item, and Headhunter has already moved really far towards being just pure power over being deeply weird and letting weird things happen, even if you have to be prepared for some of that weirdness to mess with you. Shroudwalker isn't even new; it was one of the original nemesis mods, and the first time that was stolen during testing was absolutely a highlight - that interaction has always been a part of the item, and that's a feature, not a bug.

The core identity of the item as giving you the mods of the monster i...

They do. Anytime you steal a mod, it discards any existing stolen mod effect on you that is the same mod, then adds the new one for the full duration.