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.
