Collectible Card Game Headquarters

i want to test
Marath, Will of the Wild with
Animar, Soul of Elements and
Chorus of the Conclave

in the current forge snapshots Animar does not work with Chorus and Marath does not exist as card yet

I've merged the two implementations of ChangeZone effect, the part for hidden origin.
There remains an only "if(isHuman)" on card choice (this is to be solved soon as well - the problem is that I have to pass origin and dest zones to choose card method for AI)

Since the rest of logic is now shared, please test if it works as intended.

@ Max: Maybe this report is related to the change from isHuman to the new logic implementation, please take a look:
viewtopic.php?f=52&t=6333&start=2745#p145217

- Agetian

I got curious about the possibilities of implementation of Soul Burn since, on the one hand, it's pretty close to Drain Life but, on the other hand, has one awkward bit to it that requires some thought and new design decisions ("...no more than the amount of B spent"). What do you think would be the best way to implement this card design-wise? We can already limit the mana spent on X to two colors (B and R), but we can't count each color individually as the player pays the X part of the mana cost, it doesn't seem to be currently possible to query which mana ability was activated in order to pay for each particular component of X. Does anyone know what would be a sane approach to implementing this shard-based count? I have some crazy ideas in my mind but they seem pretty suboptimal and have some deep-going consequences for the related code base that is likely to break things. Are there any script-side shortcuts and tricks that are possible here? What would the "ideal" script for Soul Burn look like? If anyone can come up with a mockup and give me a few pointers about what a good enough strategy for updating the code might be here, I might look into adding the relevant code to support this card (seems like it was a part of quite a few tournament decks in its time and was featured in some staple decks such as Erik Lauer's work, I think it might be worth adding this card to the list of supported ones with time).

- Agetian

I don't think the script to Soul Burn is all that interesting. It's really not going to be different than Drain Life, except for the "how much life do I gain part"

Soul Burn | Open

# This part targets, and sets the "Limit" SVar to the Toughness of the Creature or the Life of the Player as appropriate
A:SP$ StoreSVar | Cost$ X 2 B | XColor$ BR | ValidTgts$ Creature,Player | TgtPrompt$ Select target creature or player | SVar$ Limit | Type$ Targeted | Expression$ CardToughness | SubAbility$ StoreTgtP | ConditionDefined$ Targeted | ConditionPresent$ Card.Creature | ConditionCompare$ GE1
SVar:StoreTgtP:DB$ StoreSVar | SVar$ Limit | Type$ Count | Expression$ TargetedLifeTotal | SubAbility$ DBDamage | ConditionDefined$ Targeted | ConditionPresent$ Card.Creature | ConditionCompare$ EQ0
# Simple Damage
SVar:DBDamage:DB$ DealDamage | Defined$ Targeted | NumDmg$ X | SubAbility$ DBGainLife | References$ X
SVar:X:Count$xPaid


SVar:DBGainLife:DB$ GainLife | Defined$ You | LifeAmount$ DrainedLifeCard | References$ DrainedLifeCard

SVar:DrainedLifeCard:SVar$BlackManaPaid/LimitMax.Limit
# Limit gets overwritten by the SVars above to Life or Toughness
SVar:Limit:Count$xPaid
SVar:BlackManaPaid:Count$xColorPaid B

The basic idea is the same as DrainLife, when the spell first starts resolving it sets the Base value of the Player's life or the Creature's toughness. Then it deals damage equal to the total value of X. Then the following math formula is being calculated:

LifeGain = Math.min(B paid for X, Toughness/Life of Target)

x values would need to track which mana shards were used to pay for them, which may be complex in a future Forge where all X values are announced.

Thanks for the information, Sol! Now, the important part is actually implementing a way to count different shards used to pay for X.

As such, a question for someone familiar with the relevant part of the code (so that I don't duplicate anything or do the wrong thing here...): with the current code base, is it possible to retrieve the exact shard that was used to pay for the component of X by accessing something in SpellAbility or the ManaAbility of a card the mana ability of which was activated during the payment of X?

- Agetian

Agetian wrote:Thanks for the information, Sol! Now, the important part is actually implementing a way to count different shards used to pay for X.

That won't be shards (parts of manacost), but multiple mana... motes(?) - those things floating in your mana pool.


I've made some changes in 24862-63 - now you can access Mana items used to pay spells (but not just any ability) from forge.game.spellability.SpellAbility.getManaPaid() method

PS: There's also a chance I've broken everything and planted a dozen of bugs... well, as I usually do =)

Just out of curiosity, is there possiblity to track MultiKicker (or Replicate) mana spent when casting a spell? If possible, "Total Mana Spent" cards can be scripted.

Max mtg wrote:

Agetian wrote:Thanks for the information, Sol! Now, the important part is actually implementing a way to count different shards used to pay for X.

That won't be shards (parts of manacost), but multiple mana... motes(?) - those things floating in your mana pool.


I've made some changes in 24862-63 - now you can access Mana items used to pay spells (but not just any ability) from forge.game.spellability.SpellAbility.getManaPaid() method

PS: There's also a chance I've broken everything and planted a dozen of bugs... well, as I usually do =)

Thanks for the implementation, Max, will use this to work on getting things going for Soul Burn soon!

- Agetian

swordshine wrote:Just out of curiosity, is there possiblity to track MultiKicker (or Replicate) mana spent when casting a spell? If possible, "Total Mana Spent" cards can be scripted.

Any mana paid through forge.game.mana.ManaPool.tryPayCostWithMana(SpellAbility, ManaCostBeingPaid, Mana) is accumulated into that list.
Mana paid for Replicate and multikicker, as I remember, does flow through that route.

Max mtg wrote:

swordshine wrote:Just out of curiosity, is there possiblity to track MultiKicker (or Replicate) mana spent when casting a spell? If possible, "Total Mana Spent" cards can be scripted.

Any mana paid through forge.game.mana.ManaPool.tryPayCostWithMana(SpellAbility, ManaCostBeingPaid, Mana) is accumulated into that list.
Mana paid for Replicate and multikicker, as I remember, does flow through that route.

I was trying to script Jeweled Amulet and found a bug. forge.game.spellability.SpellAbility.getManaPaid() adds existing floating manas in the mana pool.
1) Tap a Plains to add W to your mana pool.
2) Tap a Forest to activate an ability (Cost 1). forge.game.spellability.SpellAbility.getManaPaid() returns W G.

That's the weird autoplay, that attempts to pay mana with the same instances as used for real payment,
I always told this autopay feature should not be there.

Max mtg wrote:That's the weird autoplay, that attempts to pay mana with the same instances as used for real payment,
I always told this autopay feature should not be there.

If auto-payment is broken, then so is AI mana payment, since they use the exact same logic. Instead of contemplating removing the Auto button, can we just fix the AI logic?

You may not find the Auto button useful, but I know for a fact that many do. It's also a nice way to test the AI logic.

drdev wrote:

Max mtg wrote:That's the weird autoplay, that attempts to pay mana with the same instances as used for real payment,
I always told this autopay feature should not be there.

If auto-payment is broken, then so is AI mana payment, since they use the exact same logic. Instead of contemplating removing the Auto button, can we just fix the AI logic?

You may not find the Auto button useful, but I know for a fact that many do. It's also a nice way to test the AI logic.

AI mana payment is not broken, not when it has no spare mana in pool. Just put a breakpoint at ManaPool.java, line 332 and see when it gets hit:
1. AI is paying for an ability (ai does not reach this place when it choses which spells it can afford)
2. Human pays for a spell or ability.
3. "Autoplay" feature checks if it can pay for the spell with mana form pool.

Without autoplay it would work properly.

Probably, some people might like autopay, but it's poorly implemented and stands on the way of adding new cards.
I remember your words that code should not stand on the way of new features. Let's apply this principle here!

UPD: Oh, great! I found a way to remove some ai-specific code form game.
Wait here.

Yes, I know! that AI tests were not intended to check partially paid abilities.