Let the AI count converge before it decides whether to cast

[liamiak]

Supersedes #11485 — the two were halves of one change, and the duplicated payment simulation you
flagged could only be resolved in one place.

Converge and sunburst count the colours actually spent, which nothing has while the AI is still
deciding. Two things followed from that.

X was never announced to buy them. PermanentAi measured its converge baseline at the maximum X
setMaxXValue leaves behind, so its walk always compared worse and X collapsed to 0. That loop is
deleted — setMaxXValue is where every X announcement already goes. It still returns the largest
affordable X, so the xPay <= 0 checks at its 66 call sites are unchanged, and it only acts on a
spell, since converge counts colours spent casting. Sweep the Skies is then fixed without touching
TokenAi.

card	before	after
Chamber Sentry	never cast — at X=0 a free 0/0 that dies	5/5
Skyrider Elf	2/2	5/5
Sweep the Skies	one thopter	five

Count$Converge read 0 while deciding. getCastSA() is null before the spell is cast, so Bring
to Light searched for a 0-drop and never cast. canPlayAndPayFor already lends the card its
castSA for this reason; it now lends the payment too. getConvergeCount derives from
getConvergeColors, so there is one simulation rather than two.

Then it tutored for the worst card. chooseCardToHiddenOriginChangeZone treats
Destination$ Exile as dumping junk, so on your own library it takes getWorstAI — Bring to Light
picked a Runeclaw Bear over a Serra Angel 18/18. Exile is a staging step before DB$ Play. Eight
unflagged cards share this. Scoped by calling the chooser across every destination × origin ×
own-or-opponent: one cell of thirty moves.

Engineered Explosives stays flagged. Its counters select which mana value the wipe hits, so most
colours is usually the worst live choice — that needs board-aware selection, separately.

Each commit fails its own assertion without it. 338 tests, 0 failures.

🤖 Implemented with the assistance of Claude Code (Opus 5).

[tool4ever]

don't like having to create extra fake Mana

what are the alternatives?

[liamiak]

You're right — I missed this one on the first pass. Working it now, expect another push.

[liamiak]

Pushed. Went with predicting the colours rather than the payment: a byte predictedPayingColors on SpellAbility that getPayingColors() ORs in, set and cleared on the same lines that already borrow and return castSA.

payingMana is a multiset with provenance and the prediction is only a set of colours, so the Mana objects were right about colour and invented the rest — one entry per colour, each sourced from the spell itself, which is what Count$Adamant, Count$TotalManaSpent and Count$EachSpentToCast read.

On the redundancy point: getSunburst() had no callers left once getConvergeCount was rewritten — it was ColorSet.fromMask(sunburstMap).countColors() over the same field getColorsPaid() returns — so I removed it. Happy to put it back if you'd rather keep the accessor.

To be straight about the scope: the mask is only set for hasConverge() cards, and none of the 31 in the pool use ManaColorsPaid or ManaSpent, so Count$Converge is the only reader that can observe a non-zero value today. Outside the AI's own evaluation getPayingColors() is unchanged.

[tool4ever]

Mhn, I'll think about it though a lot of work has previously gone into removing AI only stuff from the main rules engines...

[tool4ever]

don't mind a more generic solution but then you need to replace the specific variant above
otherwise we end up with duplicated logic that also wastes runtime
though the ones with X will probably make things tricky 🤔

[liamiak]

Agreed, and that's done as of the push after your review — getConvergeCount is now just ColorSet.fromMask(getConvergeColors(sa, ai)).countColors(), so there's one payment simulation rather than two. Same result either way: getSunburst() was already ColorSet.fromMask(sunburstMap).countColors() and getColorsPaid() returns that same mask.

The X ones are in that push too — X gets announced before the colours are measured, since on those cards X is what buys them.

[tool4ever]

well the code duplication is gone but the method is still used and calculates again for no reason?

[liamiak]

Pushed two commits.

reuse the converge colours the X search already found — the recompute you spotted. setXForBestConverge now returns the mask it settled on instead of the caller working it out again: 13 → 12 payment simulations casting Chamber Sentry off five lands.

offer the converge prediction through PlayerController instead — an alternative for your point about AI-only state in the rules engine. Not meant to land alongside the field version; take whichever you prefer and I'll drop the other.

It parks nothing on the spell. getPayingColors() asks the activating player's controller what it means to spend while nothing has been spent; PlayerController answers 0 so humans are unchanged, and PlayerControllerAi forwards to what AiController worked out. One seam still serves Converge, Count$ManaColorsPaid and both ManaSpent checks, and there's no mask left to go stale.

Scoped twice — canPlayAndPayFor hands back whatever the outer spell was expecting, so a nested evaluation can't lose the outer prediction, and chooseSpellAbilityToPlay resets it next to AiCache.clear() and predictedCombat. HELD_MANA_SOURCES_FOR_NEXT_SPELL four lines up is the same species of state: good for one spell, kept AI side, reset at priority.

The honest trade: the field version is +17/−21 across three files, this is +60/−17 across six, and the prediction becomes controller-scoped rather than spell-scoped, so a runWithController swap loses it. Both cases degrade to 0, which is the answer before any of this.