Am I mistaken in understanding that reflect will reflect back half damage?
But I also thought the total fatal damage was based on the troops health + armor (cos that’s how it’s displayed in-game) and it’s not just a flat huge number. Which means even when halved from reflect, is still fatal..
it reflects 99999 damage, no matter how you halve it. Workaround was to cleanse the target, and here we got a troop which applies buff on self when taking damage - which happens just after cleanse effect
AFAIK, ‘kill’ has been hardcoded as some very large damage figure, instead of the more reasonable ‘kill switch’ that bypasses inflicting actual damage.
This approach has caused issues throughout, like when Archer’s 3rd trait triggers on a troop with reflect, killing the Archer too (they called it working as intended, but it has the scent of ‘oopsie but not worth the effort fixing’), or when Ubastet kills a hero with the Saviour talent, and the resulting Barrier prevents the second troop from being killed (not sure if this has been fixed, haven’t encountered the scenario in a while).
Basically, the choice of implementing ’Kill’ as ‘here’s a boatload of damage’ causes issues every now and then, like it’s happening with Dark Oracle (Zuul Dispels > Sends Boatload of Damage > Damage triggers Dark Oracle 1st Trait reflect > Everything dies)
This is inconsistent with "the “Aquatic” trait, which also triggers upon taking damage but is processed AFTER the actual damage.
Currently, the Dark Oracle’s trait is tantamount to having Reflect on 100% EVERY time it takes any damage. Which could be reasonable thematically, but it’s kind of way too powerful and especially for a first trait…
Reflect has always been based on damage as calculated, not the actual HP lost.
But lethal damage (at least for spells) also got tweaked at some time ago to Dispel the target before killing, perhaps specifically to deal with the target having Reflect status.
if you look closely, aquatic being applied instantly, it just doesn’t avoid the aoe damage which triggered it - because this filter only happens on spell cast event.
Seems like the trait is bugged and applying reflect BEFORE damage, instead of AFTER damage.
Fix that and this wouldn’t be an issue any more. Because it would take damage and die, with no reflect to kill the attacker. And if it takes damage and gets reflect, then takes instant death damage, it would be dispelled then, and not have reflect when taking the damage.
Dark Oracle’s reflect is like the iron maiden curse from Diablo 2–damage dealt is damage received. I charged in with my Barbarian and took a swing at some daemons and got destroyed with just one frenzy swing, while my corpse exploded on the floor. Good times.
Only Zuul do dispell the target before killing - just try to use it on a submerged maelstrom - it would dispell a submerge with no damage and harm. Noone else can do this.
I’d call this a “feature, not a bug”. This feature doesn’t overturn the win/lose situation in gameplay, and is perfectly explainable in mechanics. So no reason to spend efforts to “fix it”.
What do you mean? The trait is supposed to apply reflect AFTER taking damage, and instead applies it BEFORE taking damage. That is a bug. Not a feature.
You can lose a troop, possibly your last troop, and thus lose the battle, when you aren’t supposed to. If you target a troop that doesn’t have reflect, and try to kill it, you are not supposed to lose your troop. With this bug, you do.
As for whether or not reflect should kill your troop as well, the jury is out on that and it’s been argued for years. But if the troop does NOT have reflect, it shouldn’t suddenly get it and kill your troop unfairly. That is clearly bugged.
I disagree. It might just be one troop, but the trait is bugged and they could give it to other troops later, so it should be fixed.
And let’s be honest. It’s one bit of code that is applying a status effect before something instead of after something. It should be an easy, quick fix. Not hours or days of work rewriting an entire game mode. This is something small that can be thrown in as part of the “minor fixes” section tacked on to the end of most updates. It’s not a priority, but when they get a chance, they should fix the bug.
I’m aware that all eyes are on 9.1 right now, but hoping that the following suggestion gets added to the report: if we spend a little extra time fixing the ‘kill’ code once and for all to make it so it stops counting as damage, we may save time in the long-term by not having to chase these unwanted scenarios when they periodically arise.
