[Not a bug] Spells boosted by blessed allies do not benefit from caster

Just replying to confirm this isn’t a bug. Blessed is dropped when casting a spell, leaving Vanya with 3 Blessed allies for a boost of +12 damage, 48 + 12 = 60.

I will pass feedback onto the team that you’d like Blessed to be removed from Vanya after the spell is cast, rather than before.

4 Likes

Or that the tooltip would report the damage to be made accurately…

2 Likes

In that case the spell text would need to be changed also. Not that it’d be difficult—“boosted by blessed allies” → “boosted by other blessed allies”—but that’s two changes to the game where changing the spell is just one.

4 Likes

If the status is always dropped before the actual damage calculation, every time the caster himself has a status that boosts the damage, there is no consistency between the actual damage and the damage informed to the player immediately before the casting at the “green cast-button screen”. If you do not want to call that a bug, ok, but at least that is very counter-intuitive.

That’s the actual bug then. The way the damage calculation UI is designed is not how the game actually operates. So it’s misleading.

But to be fair to @Kafka… That’s not what the OP reported as bugged.

What I was trying to hint at earlier. But, my olive branch was brushed away with mockery.

How many troops in the game do damage two targets. And then one when there’s only one troop alive. Some of those troops do double damage to a single target. While others do only normal damage.
With absolutely no way to tell based on the text.

To me, that’s a way bigger inconsistency than any shitty troops boost inconsistencies. But not a big enough issue to dedicate my time to. Since every time I get close to addressing it…a Lycanthropy type issue pops up instead.

3 Likes

Yeah, sorry I hyper focused on the spell damage itself, I will give feedback about the boost shown prior to the spell being cast as well.

7 Likes

I found some consistency but prove me wrong.
When the text says does dmg to the first 2 enemies, or 2 last enemies or first and last enemies, it will only do dmg once when only 1 enemy left. If it says do dmg to 2 random enemies, it will do dmg twice.

If the dmg is correct and the tooltip is wrong, then the interpretation of “ally” is inconsistent in the game. See my post about the beastly claw weapon in this thread.
Sometimes self is counted as an ally and sometimes not?

As far as I know, “allies” always includes the hero or the troop casting the spell. “Other allies” (e.g. Queen Aurora) excludes the caster.

4 Likes

Not in the case when spell effect is boosted by blessed or submerged allies, and also the special case of VoO whose dmg is boosted by all allied mana.

You are misunderstanding how the game works. The inconsistency is not “what does ‘allies’ mean”, it is “when are blessed/submerged/mana removed relative to casting the spell and doing damage”. The tooltip is wrong—not because it isn’t calculating the damage correctly, but because the state of your team changes between when you click “cast” and when damage is actually dealt.

4 Likes

I understand that and I think it is a bug.
Lets take a look at a similar problem also mentioned in this thread.
Webspiner and the triple dmg. Webspiner applies webbed ON skull dmg, not BEFORE skull dmg. According to you it is ok that webspiner does x3 dmg all the time, just because the state of the enemy team changes before the dmg is actually dealt, since traits are evaluated before first.

Now that we can agree on, even though we disagree about the nature of the bug.

to be more precise one of the two options would be best:

  • change it so that all of the ‘on cast’ effects are applied after spell damage is being applied (‘on cast’ effects are: removing mana from caster troops, removing any current or future postive effects that lasts until unit casts or attacks → bless and submerge now, but they might show up in future, gaining stats when ally casts → so troops with Arcane wouldn’t be buffed before their own spellcast, same goes for all enemy abilites that go same way)
  • change tooltips to at least don’t include casting troop for tooltip damage calculation when it’s taking in concern for these 3: submerge, bless, owned mana (and any future based on buffs, that get removed on cast)

Don’t know how code looks like, but it seems to me, that although switching when “on cast” effects are applied would change the way the game plays for lots of troops, it might be “easier” to implement, than adding some extra “if” options for calculating bonus damage in tooltips…

But basicaly, if any feedback from this thread it’s to fix this issue globaly:
"Tooltips for troop bonuses in some cases display greater damage numbers than actualy are applied. All cases involve situation, when bonus is using submerge/bless status or unit mana, which are removed from casting troop, before damage is being calculated and applied.

Players would like to have either of these:

  • fixed formula for tooltips, to explicity ignore caster troop, when bonus damage is counted for submerge/bless status, caster unit mana
  • changed order of spell resolve: damage dealt should be calculated before any “on cast” effects are applied"
3 Likes

Realistically, thinking about it, players would probably also get confused when seeing a tooltip that only calculates a boost for 3 allies when they have the status effect on all 4 (without knowing the order in which status effects and spells resolve) – and then we’d see the reverse bug report;

unless one of the other changes is made, e.g. the spell wording per Grundulum, the resolution order of status effects and spells, passed on by Kafka, or the spell reworked in some other fashion.

Well, thanks for daring to enter the lion’s den, I hope a bit of mauling won’t dissuade you from returning.

Similar bug reports where the issue was forwarded, never to be heard of again:

Similar bug reports where the issue received the full apathy treatment:

It feels unlikely that anything will change this time around. Maybe it would be easier to just add it to the Known Issues list? Might prevent the next player from wasting time by reporting it yet again in a few months.

5 Likes

It is a game. Nobody reads the known issues page, I never did for sure.
But your nice collection of bugs show that other think this bug just like me, or at least many other players got confused.

I’m pretty sure people do, especially since it’s an explicit instruction given in the Bug Report template if I’m not mistaken.

EDIT for links proving I’m not mistaken (though I guess not everyone reads everything? :man_shrugging:):

Oh I remember now, I read it once. Contains almost nothing.
If we would collect all the known issues from the forum the list would reach from Mako to Jerusalem.

OFF: Cultural moment
Mako is a city in Hungary, when we want to express that two things are very far away we say "it is as far as Mako from Jerusalem, in this case the two ends of that list :slight_smile:

@Fourdottwoone I will bring it up again with the team to make sure it’s not falling off the radar.

@Tibo I try to keep the known issues list updated with the most urgent/critical/important bugs for the community and only confirmed bugs will be added there.

I’m sorry if it’s not so useful at the moment, hopefully in the future we can improve on it - but it will take some time. It’s something I want to improve but I need the time to do it - and getting more time for this sort of thing is what we’re working on at the moment.

1 Like