Bug Reports (snapshot builds)

[stormcat]

:r32906
Boonweaver Giant should be able to search graveyard, hand and library,
but it seems to search only library now.

[Agetian]

:r32906
Boonweaver Giant should be able to search graveyard, hand and library,
but it seems to search only library now.

It actually kinda works, but in a really janky way. If you answer "yes" to the question of searching in the library, it'll let you search the library and then bail out without letting you look in the graveyard and hand (while ideally it should let you look in other zones), but if you answer "no", it'll let you pick a card from graveyard and/or hand (from a list), actually without letting you know which one is coming from your graveyard and which one is coming from your hand... This definitely needs some improvement. :/

- Agetian

[stormcat]

＠Agetian
Oh, Thanks.I didn't notice.

Then, I found a problem.
The ability of Boonweaver Giant can search aura that can't enchant creature, but it should not be able to enter the battlefield.
This is written in release notes.
I tested by Animate Dead.
Animate Dead is entered the battlefield, and put graveyard.
It is incorrectly behavior.

[stormcat]

:r32906
When the creature that has activated ability of Saffi Eriksdotter dies, it return.
Then, when dies again, it return again.
this is incorrectly behavior.

[Agetian]

:r32906
When the creature that has activated ability of Saffi Eriksdotter dies, it return.
Then, when dies again, it return again.
this is incorrectly behavior.

Fixed (r32910).
Thinking of it, it looks like the card that goes to graveyard in this case does not register as a new object for the purpose of effect that remembers it. Maybe that aspect of it should somehow be fixed instead? :/

- Agetian

[Agetian]

＠Agetian
Oh, Thanks.I didn't notice.

Then, I found a problem.
The ability of Boonweaver Giant can search aura that can't enchant creature, but it should not be able to enter the battlefield.
This is written in release notes.
I tested by Animate Dead.
Animate Dead is entered the battlefield, and put graveyard.
It is incorrectly behavior.

I tried to fix this in r32911, but I'm not sure if that's the appropriate solution :/ Basically, the special case where an aura would indirectly ETB attached to another object was not handled in case of corner cases when that aura can't legally enchant the said object (e.g. Animate Dead on Boonweaver Giant).

- Agetian

[Hanmac]

@Agetian: about Boonweaver Giant, looking at AttachEffect does show the use of tgt.canBeEnchantedBy(aura). whouldnt that be a better code than your change?

[Agetian]

@Agetian: about Boonweaver Giant, looking at AttachEffect does show the use of tgt.canBeEnchantedBy(aura). whouldnt that be a better code than your change?

Ah, yep, that seems to work well, I'll test a bit and commit. Thanks a lot!

EDIT: Committed the solution. The second part of my change is still necessary to prevent the game from not only enchanting Boonweaver Giant with Animate Dead but also recurring its trigger if Boonweaver Giant is, for example, Go for the Throat'ed with its trigger still on stack.

- Agetian

[Hanmac]

i think you got it mixed up, shouldnt it be:
"!attachedTo.canBeEnchantedBy(c)" ?

hm doesn't canBeEnchantedBy already handle the "Enchant creature card in a graveyard" and "Enchant instant card in a graveyard" keywords?

[Agetian]

i think you got it mixed up, shouldnt it be:
"!attachedTo.canBeEnchantedBy(c)" ?

hm doesn't canBeEnchantedBy already handle the "Enchant creature card in a graveyard" and "Enchant instant card in a graveyard" keywords?

Hmm, that's actually odd - you're right about it having to be attachedTo.canBeEnchantedBy(c), but that apparently does nothing for these special cases (even the basic Boonweaver Giant + Animate Dead does not pass with that test), I guess I'll need to look into what exactly canBeEnchantedBy is testing :/

- Agetian

[Hanmac]

but isn't "Boonweaver Giant + Animate Dead" should not pass because Animate Dead can't ever enchant the Giant? or is it allowed to enchant it when Boonweaver got killed?

i am currently confused what you mean with "not pass"

[Agetian]

but isn't "Boonweaver Giant + Animate Dead" should not pass because Animate Dead can't ever enchant the Giant? or is it allowed to enchant it when Boonweaver got killed?

i am currently confused what you mean with "not pass"

Yep, you're right, it's not allowed to enchant it, but it does try to enchant it if we use !attachedTo.canBeEnchantedBy(c) - that's why I said "it does not pass" as in "the test for it does not pass"... That was actually what prompted me to start coding my original fix yesterday... Basically, even with !attachedTo.canBeEnchantedBy(c), Animate Dead will ETB and then go to the graveyard, which it shouldn't do.

Hmm, it looks like canBeEnchantedBy is not suited for that particular corner case check at the moment. I tried updating it to account for the situation which is handled by checkCanAttachTo in my fix, but unfortunately, that breaks other situations (for example, if that check is integrated into canBeEnchantedBy, then Animate Dead stops working properly in normal cases, e.g. animating a creature from a graveyard). I'm not quite sure how to best adapt that function without breaking things elsewhere...

- Agetian

[Agetian]

Got a StackOverflowError when the AI blocked my trample Primalcrux with his Rhys the Exiled:

Code: Select all

Don't need a land or none available; trying for a creature.
Game-0 > java.lang.StackOverflowError
   at forge.game.player.Player.getCardsIn(Player.java:1401)
   at forge.ai.ComputerUtilMana.getAvailableMana(ComputerUtilMana.java:1027)
   at forge.ai.ComputerUtilMana.groupSourcesByManaColor(ComputerUtilMana.java:1154)
   at forge.ai.ComputerUtilMana.getSourcesForShards(ComputerUtilMana.java:473)
   at forge.ai.ComputerUtilMana.payManaCost(ComputerUtilMana.java:325)
   at forge.ai.ComputerUtilMana.payManaCost(ComputerUtilMana.java:97)
   at forge.ai.ComputerUtilMana.canPayManaCost(ComputerUtilMana.java:60)
   at forge.ai.ComputerUtilCost.canPayCost(ComputerUtilCost.java:470)
   at forge.ai.ComputerUtil.canRegenerate(ComputerUtil.java:737)
   at forge.ai.ComputerUtilCombat.canDestroyBlockerBeforeFirstStrike(ComputerUtilCombat.java:1829)
   at forge.ai.ComputerUtilCombat.shieldDamage(ComputerUtilCombat.java:609)
   at forge.ai.ComputerUtilCombat.totalShieldDamage(ComputerUtilCombat.java:588)
   at forge.ai.ComputerUtilCombat.lifeThatWouldRemain(ComputerUtilCombat.java:291)
   at forge.ai.ComputerUtilCombat.lifeInSeriousDanger(ComputerUtilCombat.java:455)
   at forge.ai.ComputerUtil.getCardPreference(ComputerUtil.java:353)
   at forge.ai.ComputerUtilCost.checkSacrificeCost(ComputerUtilCost.java:285)
   at forge.ai.ComputerUtilCost.checkSacrificeCost(ComputerUtilCost.java:363)
   at forge.ai.ComputerUtil.canRegenerate(ComputerUtil.java:748)
   at forge.ai.ComputerUtilCombat.canDestroyBlockerBeforeFirstStrike(ComputerUtilCombat.java:1829)
   at forge.ai.ComputerUtilCombat.shieldDamage(ComputerUtilCombat.java:609)
   at forge.ai.ComputerUtilCombat.totalShieldDamage(ComputerUtilCombat.java:588)
   at forge.ai.ComputerUtilCombat.lifeThatWouldRemain(ComputerUtilCombat.java:291)
   at forge.ai.ComputerUtilCombat.lifeInSeriousDanger(ComputerUtilCombat.java:455)
   at forge.ai.ComputerUtil.getCardPreference(ComputerUtil.java:353)
   at forge.ai.ComputerUtilCost.checkSacrificeCost(ComputerUtilCost.java:285)
   at forge.ai.ComputerUtilCost.checkSacrificeCost(ComputerUtilCost.java:363)
   at forge.ai.ComputerUtil.canRegenerate(ComputerUtil.java:748)
   at forge.ai.ComputerUtilCombat.canDestroyBlockerBeforeFirstStrike(ComputerUtilCombat.java:1829)
(...this repeats many times...)


This happens every time I try this particular scenario.

Looks like the following call in ComputerUtilCombat.java is the issue when being called from within canRegenerate(), since canDestroyBlockerBeforeFirstStrike eventually calls canRegenerate as well, which then calls shieldDamage, which calls canDestroyBlockerBeforeFirstStrike again, and that leads to infinite recursion:

Code: Select all

    public static int shieldDamage(final Card attacker, final Card blocker) {

        if (ComputerUtilCombat.canDestroyBlockerBeforeFirstStrike(blocker, attacker, false)) {
           return 0;
        }
...


Not sure what to do to rectify this though :/ Help is welcome.

- Agetian

[Hanmac]

@Agetian: yeah i noticed that too a long time ago ...
its the problem with "<Sac Creature>: Regenerate" cards when you attack with a Creature with Trample.

but i didn't found a way to fix it yet ...
Probably need some Simulation what creature it should sacrifice (the one with the lowest toughness?)

i think somewhere in the Recrusion we might add a check for it not to do such "<Sac Creature>: Regenerate" when blocking Trample until we found a better way to fix it.

[Agetian]

@Agetian: yeah i noticed that too a long time ago ...
its the problem with "<Sac Creature>: Regenerate" cards when you attack with a Creature with Trample.

but i didn't found a way to fix it yet ...
Probably need some Simulation what creature it should sacrifice (the one with the lowest toughness?)

i think somewhere in the Recrusion we might add a check for it not to do such "<Sac Creature>: Regenerate" when blocking Trample until we found a better way to fix it.

I managed to fix this by adding an explicit AIPreference for SacCost, it does not crash in my tests anymore. I don't know how good the logic for that is (it did sac tokens before non-tokens, and generally weaker elves before stronger elves, which seems adequate and reasonable enough), but at least it doesn't stack the smash the stack anymore.

- Agetian