Stunned countdown still going off

JD Geek

I stunned Rulk, well he stunned himself with a match 5, and the remainder of his countdowns still went off after he was stunned.

BlackSheep101

Nothing stops countdowns from ticking down once they've started going off short of downing the character. (At least I think downing them removes the c/d's...)

_RiO_

BlackSheep101 wrote:

Nothing stops countdowns from ticking down once they've started going off short of downing the character. (At least I think downing them removes the c/d's...)

Countdowns are supposed to be halted when the connected character is stunned.
That is always how they've worked.

BlackSheep101

If they're stunned at the start of the turn, yes. If they become stunned while countdowns are going off, they keep going. (IM40 is the only other example that springs to mind)

Dayv

It used to be that if a non-IM40 countdown went off between his Recharge countdowns, his remaining countdowns would stop and the stun would take effect.

I started seeing this behavior with other multiple countdown users (Rulk is a good example) who might trigger a stun during their resolution a couple weeks ago.

I suspect that a fix to a bug for IM40's countdown resolution may have given a slight buff to other countdown users, especially those likely to get multiple tiles out.

They definitely don't resolve if the owner is stunned when the turn begins.

_RiO_

Really all of these bugs come down to badly sequenced logic.

Countdown tiles counting down multiple times;
Coutdown tiles not freezing when a stun occurs;
Ares' old Sunder bug;
The Teisatsus' 'Infinite Smoke Works' bug;
etc. etc. etc.

All of it is just a patchwork of patchworks, badly interwoven into an entangled unmaintainable spaghetti mess. Every time the devs attempt to untangle it to fix a bug, something else blows up. ("Jenga!") And any time they actually do really fix all the bugs, the resulting logic is far too expensive and the game becomes sluggish as all hell, requiring them to hack back in 'optimizations' that end up reintroducing a portion of the old issues again, albeit in slightly mutated forms.

(...)

Really; tossing it and redoing it is the only way to fix these problems, imho. Not like it's that hard, even. I think I could knock out a working architecture to handle all of the board mutations and skills sequencing in a week or two, tops. So I'm wondering what the excuse is here...

Dayv

_RiO_ wrote:

Really all of these bugs come down to badly sequenced logic.

I have a recurring joke for this: "We have always been at war with order-of-operations."

Really; tossing it and redoing it is the only way to fix these problems, imho. Not like it's that hard, even. I think I could knock out a working architecture to handle all of the board mutations and skills sequencing in a week or two, tops. So I'm wondering what the excuse is here...

I suspect that tossing it and redoing is a bit more work than you imply. At a larger level, an inherent problem is that this is a live, for-profit product. If you want to remove and re-add the framework from scratch, you have to halt all other development until it's done so that you're not regression testing new features people are trying to add to the chunks of the code you're already done rewriting. Due to financial requirements of a profit-driven enterprise, development is focused on the chunks of the product that drive new user adoption and increased sales rather than those that might just decrease their churn rate very slightly. By the time most of use have been playing long enough to notice a bug like this one, we're already hooked.

That said, I once posited a pretty discrete bit of handling to fix countdown processing that I think would solve the issue without a total rewrite, and without greatly impacting resource load. This particular problem can be fixed without tearing down the house to start over.