Multi-Targeting Issue

[slapshot5]

I found something very weird:
For some reason this fixed the issues with the human input killing spells on the stack (unless costs, Ulamog, the Infinite Gyre and Deathbringer Liege). Maybe someone else can double check this. It would be fantastic, if it is true.

Something fixed it anyway. My Ulamog, the Infinite Gyre is on the battlefield right now.

-slapshot5

[friarsol]

I found something very weird:
For some reason this fixed the issues with the human input killing spells on the stack (unless costs, Ulamog, the Infinite Gyre and Deathbringer Liege). Maybe someone else can double check this. It would be fantastic, if it is true.

Something fixed it anyway. My Ulamog, the Infinite Gyre is on the battlefield right now.

I'm totally taking credit.

[jeffwadsworth]

I just find it unnerving that a crazy error gets fixed and no one knows how...

[Sloth]

The unless cost is still not fixed as it seems , but the rest is .

[friarsol]

I just find it unnerving that a crazy error gets fixed and no one knows how...

I was making in changes in that area of the code. I just wasn't looking for this specific bug. I definitely fixed a few things related to how the Stack is grabbed from other states (specifically the Display) which was causing some serious issues with the targeting. I wouldn't be too surprised if that was what fixed it.

[friarsol]

I got a few hours tonight to look at Multi-triggering. I successfully ran a test where both my Memnite and my Uktabi Orangutan was snuffed by the AIs No Mercy.

To get it to work using the StackInstance system, I had to convert the TriggeredObject from being on the Card to on the SpellAbility (which makes more sense to me). It looks like it was originally put on the Card so it can be accessed in xCount. So I had to make some tweaks to about 65 cards or so that was using Values from Trigger, to use a different check. I'll see if I can get a few more hours in the next few days to test some of the cards I changed, and I'll try to test some of the scenarios Soulstorm posted above, but it looks like this should be ready to go pretty soon.

Edit: I just tested a scenario with Ageless Entity, Bottle Gnomes, Spike Feeder, and Braidwood Cup. I activated the life gains one at a time in response to the Entities trigger. He successfully gained the correct amount of counters in reverse order (as expected). I'll try to test tmrw night so everyone else can play soon.

[Sloth]

I got a few hours tonight to look at Multi-triggering. I successfully ran a test where both my Memnite and my Uktabi Orangutan was snuffed by the AIs No Mercy.

To get it to work using the StackInstance system, I had to convert the TriggeredObject from being on the Card to on the SpellAbility (which makes more sense to me). It looks like it was originally put on the Card so it can be accessed in xCount. So I had to make some tweaks to about 65 cards or so that was using Values from Trigger, to use a different check. I'll see if I can get a few more hours in the next few days to test some of the cards I changed, and I'll try to test some of the scenarios Soulstorm posted above, but it looks like this should be ready to go pretty soon.

Edit: I just tested a scenario with Ageless Entity, Bottle Gnomes, Spike Feeder, and Braidwood Cup. I activated the life gains one at a time in response to the Entities trigger. He successfully gained the correct amount of counters in reverse order (as expected). I'll try to test tmrw night so everyone else can play soon.

I can't wait for it.

[jeffwadsworth]

Sol, it's amazing that you happen to mention this...I was messing with Lightmine Field last night and its trigger affects just one of the attackers. Your solution sounds like it would fix this.

| Open

Name:Lightmine Field
ManaCost:2 W W
Types:Enchantment
Text:no text
T:Mode$ Attacks | ValidCard$ Creature | Execute$ TrigDamage | TriggerZones$ Battlefield | TriggerDescription$ Whenever one or more creatures
attack, CARDNAME deals damage to each of those creatures equal to the number of attacking creatures.
SVar:TrigDamage:AB$DealDamage | Cost$ 0 | Defined$ TriggeredAttacker | NumDmg$ X
SVar:X:Count$Valid Creature.attacking
SVar:Rarity:Rare
SVar:Picture:http://www.wizards.com/global/images/magic/general/lightmine_field.jpg
End

[friarsol]

Alright had a bunch more succesful tests, one small tweak to handle Delayed Triggers storing their Trigger Objects (without a cards.txt change). I think this puppy is ready for you guys to try to break it. Hopefully there won't be anything major, but we should have plenty of time to test away.

[Sloth]

Alright had a bunch more succesful tests, one small tweak to handle Delayed Triggers storing their Trigger Objects (without a cards.txt change). I think this puppy is ready for you guys to try to break it. Hopefully there won't be anything major, but we should have plenty of time to test away.

The multi target tests were positive so far.

The change did break the unless cost for abilities though. It's no big deal since it was broken for spells already. I think the problem is, that the human input [GameActionUtil.payManaDuringAbilityResolve(source + "\r\n", ability.getManaCost(), Command.Blank, unpaidCommand);] will hold back until the spellability completely resolves (you can see that subabilities like that of Runeboggle happen before the input) and when the input resolves and calls "sa.resolve()" the sa is no longer there.
Any ideas how to fix this?

[friarsol]

The change did break the unless cost for abilities though. It's no big deal since it was broken for spells already. I think the problem is, that the human input [GameActionUtil.payManaDuringAbilityResolve(source + "\r\n", ability.getManaCost(), Command.Blank, unpaidCommand);] will hold back until the spellability completely resolves (you can see that subabilities like that of Runeboggle happen before the input) and when the input resolves and calls "sa.resolve()" the sa is no longer there.
Any ideas how to fix this?

Ahhhh. That makes sense, since the code doesn't wait for Inputs to move onto the next step in the code (which would be preferable in most situations). Short term solution is to have callbacks.

Something like this should work.

Code: Select all

GameActionUtil.payManaDuringAbilityResolve(source + "\r\n", ability.getManaCost(), paidCommand, unpaidCommand)


where paidCommand will resolve just the SubAbility, and unpaidCommand will resolve the sa and then the SubAbility. We probably should have a finishedResolving() call in those callBacks if sa doesn't have a SubAbility to call finished Resolving, which would then allow the Stack to finish it's Cleanup up of the Ability (anything MagicStack.resolve() would need to be split into this finishedResolving function)

[Sloth]

Ahhhh. That makes sense, since the code doesn't wait for Inputs to move onto the next step in the code (which would be preferable in most situations). Short term solution is to have callbacks.

Something like this should work.

Code: Select all

GameActionUtil.payManaDuringAbilityResolve(source + "\r\n", ability.getManaCost(), paidCommand, unpaidCommand)


where paidCommand will resolve just the SubAbility, and unpaidCommand will resolve the sa and then the SubAbility. We probably should have a finishedResolving() call in those callBacks if sa doesn't have a SubAbility to call finished Resolving, which would then allow the Stack to finish it's Cleanup up of the Ability (anything MagicStack.resolve() would need to be split into this finishedResolving function)

The quick fix you suggested seems to fix the unless cost for abilities, but not for spells. I will try to code up something like finishResolving().