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.
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? ):
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
@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.
I appreciate the effort, it’s unlikely to change anything though.
The issue here is that spell handling could reasonably go both ways, either the boost taking effects removed by casting the spell into account or the boost taking effects removed by casting the spell not into account. No matter which way it is set up, players will keep reporting it as a bug.
As others have pointed out, the obvious solution is to make the spell boost only off status effects on other allies, not the caster themself. However, this requires:
1.) The spell effect to be specifically coded to only boost off status effects on other allies. Current handling seems to take all allies, including the caster, into account, which throws off boost prediction shown in-game.
2.) The spell description to be changed accordingly.
This isn’t just for one spell, there are several that would require this treatment. As the past years have shown, even just unifying trait descriptions is a task long promised and never started, this one would involve coding effort on top. It feels unlikely that anybody would consider working on it, even after hell freezes over.
This topic will predictably resurface in a few months and draw a fairly large amount of community attention, because quite a few players have been bitten by trusting the incorrect boost numbers. Like the last half a dozen times it will eventually run its course over the next weeks, with everybody involved in the very same futile discussions carrying some extra bad feelings towards the devs out of it. Something to point future bug reporters to might be able to head this off early.
It will resurface because it works illogically.
If the devs of this game not a bunch of total idiot they use some common code for handling status effects and dmg boost. Since all spells which are boosted by blessed or submerged are broken the same way I assume they are not total idiots and indeed have a common code which handles spell cast.
The only thing they have to do is calculating the dmg boost as the very first thing during a spell cast. Probably a couple lines of code must be moved upward by a few lines.
I think this topic was discussed to exhaustion, nothing more can be said about it.
You don’t have to select issues and make a fancy page, just generate a list from the bug tracking system.
It’s not standard business practice to publish everything from bug tracking tools, but I’m sure we’ll find a better solution in the future.
For all spells or only for those that boost off Bless/Submerge?
If it’s the former, that would be a nerf to everybody who uses non-bless-non-submerge-effect-on-allies as a boost (for example, Reflect (Mirror Queen), Barrier (Jotnar); Enrage (Berengari; Black Bjorn; Doomclaw).
What are the chances that trying to implement this accidentally breaks boosted-by-ally-type/kingdom spells, mostly those dual gem creator weapons?
This thread is starting to toe the line. We encourage civil discourse, critique, and discussion. However, if the conversation turns insulting, abusive, or inappropriate I will act. Please endeavour to conduct yourselves civilly and treat each other with respect.
I my opinion every “ally” related spells should interpret an “ally” the same way.
If the caster a certain type of troop and is accounted in damage boost like the tribe/kingdom weapons. Or any other spell which is boosted by type. Then it should treat the caster as an ally as well.
And then here are the case off allies in traits.
If self is an ally for a trait, it should be an ally for a spell too, which actually is in most cases. Except when the boost effect disappears from the caster earlier than the boost calculation happens.
In general, for those where the sequence of events that lead up to casting a spell has an effect on the boost counter. It doesn’t apply to any of the troops you listed, figuratively speaking their boost counter doesn’t change between pressing and releasing the cast button.
It doesn’t solve the underlying issue, that the design is ambiguous. They could calculate the damage as the very first thing during a spell cast. And they could instead display a lower spell boost by taking the removal of status effects into account. Both ways are perfectly viable, both lead to different results. As a designer you usually want to avoid that, because not matter which way you flip the switch, people will keep insisting that it’s handled incorrectly.
As far as I understood it there’s something like a state engine involved that runs through a pre-spell phase, a spell resolution phase and a post-spell phase, the spell itself consisting of several individual handling blocks that also get processed in sequence. If that’s correct there probably isn’t anywhere those couple of lines of code could be moved upward to, status effects would get removed in the pre-spell phase, damage calculation could only happen in the spell resolution phase. Shifting removal of status effect from the pre-spell phase to the post-spell phase as Kafka suggested would technically allow them to count for spell damage. There’s likely a huge can of worms attached though, because those status effects might then still linger around when other triggers resolve, causing them to behave differently.
Theory only, I haven’t opened the black box to take a closer look.