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.
1 Like
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.
1 Like
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.
ābugs.txtā
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).
EDIT:
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.
1 Like
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. 
1 Like
Errā¦ is it? This feels like a perfectly fine technical discussion, and it even seems to go both ways, I wish we had more of that. Not trying to be controversial, Iām really confused what the issue is supposed to be here. 
2 Likes
I noticed at least one post that was deleted later. I suspect Salty can see those posts even though we canāt, so this may be a reference to that.
1 Like
Havenāt u promised it already, over a year agoā¦?
https://community.gemsofwar.com/t/voice-of-orpheus-incorrect-damage/60740
The issue with VoOās spell dmg is known since like 2 yrs (or moreā¦?)ā¦
Was it not enough time to handle it, or did u had more important things to implement - like Lycanthropy (bringing more trouble / bugs with itself), uber-gems or fancy flashing squares on tabs - things no one needed, or wantedā¦
Would be nice if u could concentrate on taking out the old garbage first before you produce some newā¦
2 Likes