You are right… checked it during an arena run…
I still think that if you have a group of 4, they all have 3 allies
Then all the other troops and weapons have a positive bug and they are stronger than should be.
Is all this because you won’t admit that troops boosted by blessed is working as intended?
Because if you want a cross to die on in terms of GoW inconsistencies I can actually provide you with legit ones. It’ll come off as way less pathetic that way.
The great A.W.Ryan has spoken! What an honor that you have commented on my topic.
And no I don’t think that boosted by blessed works as intended, it is buggy just like boosted by submerge.
These status effects are late additions and badly designed troops suffer from incompetence of gow developers.
I reported a bug what I have found, let the developers decide what they do with it.
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.
Or that the tooltip would report the damage to be made accurately…
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.
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.
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.
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.
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.
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"
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.