Mark_GGG

You could, but at that point it's become something very different to triggering the attack - the attack isn't triggered (it's performed by it's user by playing the animation, which is just attacking), and it isn't you doing or triggering it - it's a mirage or similar totem-style object, which has all kinds of mechanical consequences. We could do that, but it would be fundamentally different enough from triggering that we couldn't call it that.

Conveniently, the only part a triggered bow skill needs is to fire the arrow, which is the simple to fake part of the animation that matches how most skills work. The other stuff in those animations is mostly to do with turning visiblity on and off for the arrow the character has ready in their hand (hide it when you fire, show it again when you reach to the quiver so it looks like you grabbed a new arrow) and making the bowstring animate - both of which a triggered bow skill doesn't really want because they would conflict with any non-triggered bow skill you were doing at the same time.

Melee skills (especially strikes) tend to have more mechanical info in the animation that makes generic triggering of them much harder.

The problem there is a skill can't have multiple triggers. Since counterattack skills already have a trigger built-in, adding another trigger would disable them.

That isn't how ancestral call works. The ancestor is entirely a client-side visual effect with no impact on mechanics - the attack is driven by your character's animation.

what would it look like?

Ngamahu's Flame.

No, really. Probably not exactlly like it, but a lot like it.

So far as I'm aware, this wasn't intentionally created to match with the other two you mentioned, but it ticks a lot of boxes that I think fit.

Fire is the element associated with strength, so it would make sense for the fire one to trigger attacks rather than spells, as a point of difference - it's always more interesting to have a cycle where one sticks out a bit than where everything is clean mirrors of each other (see added fire damage support or hatred as exceptions to their cycles, for example).

But because attacks are very animation-driven and triggered skills can't play animations on the character, we can't just trigger arbitrary socketed attacks - they just won't work (and/or will horribly crash). So it supplies it's own attack that's very generic - scaling on attack, physical, fire, projectile, ...

If this is correct, it is a bug, and I will look into it. Skill Popups are explicitly not meant to display stats from passives, gear or otherwise on the character - only stats from the skill itself. This is because if they displayed all the stats from those other sources, all your skill popups would (a) contain a lot of duplicated information and (b) be unreadable messes with hundreds of stats mixed in together and in some extreme cases not fit correctly on the screen, making it impossible or unfeasible to actually find the relevant stats in display.

This has nothing to do with this case relating to minions, just that the skill popup is fundamentally not where passive stats belong, for any skills.

At least most of the Fighting Fantasy series of gamebooks used 2d6 as their standard roll for combat, and they're one of the most notable examples of this kind of book (the series had more than 40 entries, and I had a sizeable collection of them growing up). There may have been some that needed more dice for specific encoutner randomisation, but none of them needed any non-d6 dice, I'm pretty sure.

After a lot of testing i concluded that this item must transfer life leech instances from mines to you. Means that if you detonate a mine that hit enemies you only get life leech if you already have UNdetonated mines on the ground at the same time

That is definitely not at all how it works. The only leech instances involved in this mechanic are applied directly to you, not to the mines, and leech instances cannot be moved from one thing to another.

If for example you simple throw a mine and detonate it you ll never get life leech.

This is incorrect. A single mine can and does correctly apply a leech instance to the player for each thing it hits. I have tested this in-game and it is working correctly. The amount of the leech will be low from an individual mine, but it does occur.

There is no distinction at all based on where you get certain bonuses from, nor a sequence which this can interrupt to get a value.

Conversion (gain x as extra y is a special case of conversion) applies all modifiers that would apply to either x or y (in this case life or energy shield). The "increased" and "reduced" modifiers stack additively with each other, because that's how those modifiers work. But increases are not the only kind of modifiers.

CI's "value is exactly 1, no exceptions" is also considered a modifier to life. As such, it also applies to the ES which is being converted from life, and sets the value to 1.

No, because you still take the damage first. If the hit kills you, you'll die before leeching anything.

If you survive taking the damage, you'll regain some life. But you do need to survive the full hit.

The "take x fire damage" will occur (potentially igniting you) before the removal of ignite. In this case both are caused by the same thing, so this is effectively arbitrary, but it's that way because internally stuff that is explicitly only for a specific ailment (Eye) happens before stuff that's general for any ailment (shared suffering removing) due to the way the code is structured.

Eye's "take fire damage" is part of the "apply an ignite" process, where shared suffering removing ailments is part of the "apply all the ailments this hit will apply" process, which is a step "further out" - so it occurs after all the individual ailment functions have been called.

Yes, if the damage taken from RF (and any other degen) is more than or equal to 20% of your max mana per second (which is very likely).

If RF is somehow dealing less damage than 20% of mana per second, then the mana drain will only be enough to exactly counter degen.

However, this doesn't and can't account for other forms of life recovery that are also countering RF - it can't "see" any other forms of life recovery, just total life loss per second, so it scales it's effect to counter that, even if you have enough regen to already fully counter the damage.

1) No. First the damage of the hit is calculated. You aren't shocked yet, so that modifier isn't in effect. Then the calculated damage is applied to the enemy - this shocks the enemy, and because of the reflection, the same shock application also applies to you. Once shock application is done, shared suffering sees that you applied a shock, and thus removes shock from you.

2) I'm not clear on specifically what you're asking here, could you please clarify in more detail what interaction you're asking about?

Shared Suffering does not transfer ailments from you to enemies. It means that : a) If you have a specific ailment, all your hit damage is counted towards causing that ailment on-hit. b) If you inflict an ailment, all ailments of that type are removed from you.

So assuming you do enough total damage to inflict shock, you'll shock the enemy, which because of reflection also shocks you again (you have two shocks now). Then all shocks are removed from you.

Your minions that are in range of Hatred are allies affected by an aura from your skills, and thus will gain the bonuses listed.

The "not removed at full mana" part does also apply to the bonus effects. The curse immunity will not be removed on reaching full mana, where without the enduring mod it would be. That mod just doesn't grant the bonus effect the ability to be infinitely stretched beyond the duration of the flask.

If the flask effect is not removed at full mana, then using the flask will definitely grant both the mana recovery and the curse immunity for the full duration of the flask. Those just might not happen simultaniously, since one of them (the recovery) can be put on hold by using another flask (or the same one again) due to the queuing mechanic, and the other one can't be. The enduring mod is still having the specific effect it says it grants on both parts.

The secondary effect is also not removed at full mana. It just doesn't get infinitetly extended by queueing - it can never last longer than the duration of one use of the flask, despite not being removed at full mana.

1) No. The loss of life over time is very low due to being based on your max life of 1, as such it can be trivially countered by a small amount of flat life regen

2) You cannot. You can be losing life over time, and this is tracked, but the loss is only applied to your actual life value once it reaches at least 1.

3) Blood Rage deals physical damage, and most CI characters chose to have energy shield because they are cowards. Ususally they recover this shield faster than the damage and thus it never gets applied to life.

In the case of a CI character with no ES, it does kill them in pretty much the same way, but at least this character dies knowing his ancestors are proud of his actions, instead of surviving as some snivelling wretch who needs to hide their life behind some blue mess to feel confidant.

4) As noted above, minimal amounts of life regeneration. If you regenerate at least as much life as you're losing, then you'...

/u/Lluga is correct. You are on 1 life. However, the game does still track partial degen (it has to for any of it to really work), and actually subtracts 1 life when the total taken reaches at least 1 total life.

If you turn on the display of life numbers, you will see that you are at 1/1 life (and thus on max life) until the enough time has passed that the total life you have lost is 1 - at which point it can be applied to your life total. This kills the exile.

The visual display in the life orb is displaying this progress so that you are aware that this is still being tracked, so that you aren't lulled into a false sense of security.

Because you're losing life so slowly, only a very small amount of life regeneration is necessary to counter it. However, since your maximum life is 1, any perc...

This is intentional and flasks have worked this way for seven years.

Life and Mana recovery from flasks queue up (with higher-speed recovery effects going to the front of the queue), with the 'queued up' flask effects not ticking down until they come off the queue and becone active.

But bonus effects from the flask's mods operate on standard rules where only the strongest of each type takes effect, but all are ticking down. They are removed either when their associated flask effect ends, or when the duration of the flask has passed.

Originally they only ended when their specific flask effect did, but there was an abuse case with this behaviour where a player would have, say, curse immunity bonus on a slow mana flask, and then constantly use other mana flasks to ensure that the slower flask granting the curse immunity would stay at the back of the queue, and thus never expire (as well as spending lots of mana to prevent reaching full). So we added th...