Improve Homarid Spawning Bed AI

[vanja-ivancevic]

• Reuse the existing threatened-sacrifice cost path so token abilities can cash in a legal permanent that is already predicted to die.
• Keep threat detection independent of the payoff ability, then let the existing SacCost preference choose the threatened permanent.
• Keep normal TokenAi behavior when no legal sacrifice is threatened.
• Remove Homarid Spawning Bed's AI deck ban without adding card-specific AILogic or pre-payment token projection.
• Verified locally that the Bed stays idle without a threat, responds to Doom Blade, and sacrifices the threatened creature instead of another legal choice.
• This intentionally makes the Bed reactive instead of attempting to optimize proactive sacrifice value, avoiding the unresolved pre-payment architecture discussed in Let the AI count converge before it decides whether to cast #11486.

[tool4ever]

we need less AILogic for trivial stuff, not more
What about using AIPreference:SacCost...?

[vanja-ivancevic]

Good suggestion. I removed the card-specific AILogic entirely and added SVar:AIPreference:SacCost$Creature.cmcGE1. The only Java change is now generic: when a token count depends on an unpaid sacrifice, TokenAi evaluates X on a detached ability copy containing the preferred sacrifice in its normal paid-cost list. This lets AbilityUtils calculate the existing Sacrificed$... expression without special card logic. I also verified that a positive-mana-value creature enables the ability, a zero-value Camarid does not, and the same path works for Tend the Pests.

[tool4ever]

This problem trying to be solved here is pretty close to what I've already described in #11486 (comment)

I guess it's up to me to write down how this architecture should be handled, though I can't give this a high priority

[vanja-ivancevic]

Thanks, the #11486 comparison made me step back from pre-payment projection entirely. I removed the copied-ability/token-value helper and the AIPreference. The revision now reuses the existing ComputerUtil.activateForCost path: TokenAi only bypasses its normal amount and phase heuristics when a legal sacrifice is already predicted to die, and the existing SacCost selection chooses that threatened permanent. There is no new AILogic, SVar prediction, or attempt to solve proactive sacrifice value. The focused test shows that the Bed stays idle without a threat, responds to Doom Blade, and selects the threatened creature over another legal sacrifice.

[vanja-ivancevic]

Post-revision self-review: the Java path is generic and one-pass. It runs only when the token amount currently evaluates to zero and the cost contains a sacrifice, uses the established sacrifice chooser, records the projected payment on a copied SpellAbility, and lets AbilityUtils evaluate the existing expression. It does not call generic playability or mana planning and does not mutate live card/game state. Homarid Spawning Bed uses the established AIPreference:SacCost mechanism rather than card-specific Java logic. The positive-mana-value, zero-mana-value, and second sacrifice-derived token scenarios pass, as does a clean forge-ai reactor build.

[tool4ever]

sacrificing everything threatened is way too generic, feels like we're running in circles

[vanja-ivancevic]

Would a card-specific SpecialCardAi path be a better direction here? I would revert the generic TokenAi and ComputerUtil changes, use AIPreference:SacCost$Creature.cmcGE1 only for sacrifice selection, and activate Homarid Spawning Bed only when that selected creature is predicted to die. This would avoid new AILogic, pre-payment projection, and behavior changes to other token or sacrifice abilities. Or would you prefer leaving the card excluded until the broader payment architecture is defined?

[vanja-ivancevic]

Sorry, I accidentally clicked re-request review.

[tool4ever]

first it depends a bit on if there are more cards that have this cost->effect pattern, it doesn't look like that research was done so far 🤷‍♂️

#11712 was a step in the right direction for how heuristics could pass information to different effect parts, however that was on Card level + between subabilities - now we need SpellAbility + between its cost

maybe it's possible together with addChangedSVars to substitute and use Remembered? but yea I'd prefer architecture outline before code dump...