Forge version 1.5.49 or 1.6.0
Posted: 29 Jan 2016, 03:27Next release TBA based on Release Managers availability.
The issue appears rather subtle and I can't, for the life of me, find the exact spot where the thing goes south. I have narrowed the problem down to the fact that somewhere in the chain of calls to resolve the ability (deal 3 damage to a creature) and the subability (deal 3 damage to the creature's controller), the targeting information in the parent spell ability (the original one) is completely lost, and when the game tries to identify TargetedController, it first looks at the subability (and finds no targets there - which is correct, I believe), then it looks at the parent ability (and finds no targets again - this is where it's definitely wrong, because when a human resolves the relevant SA, the targeted card is indeed present in the parent SA's targeted list). Once it sees no targeted cards in both SAs, the game bails out and returns no result for TargetedController because the targeted card can't be identified.
I have invented a very ugly hack that allows the card to function correctly to the AI. Namely, if we add a parameter to the parent SA in draconic_roar.txt, let's say, "PropagateTargetsToSubAbility$ True" - like this:
- Code: Select all
A:SP$ DealDamage | Cost$ 1 R | ValidTgts$ Creature | TgtPrompt$ Select target creature | NumDmg$ 3 | SubAbility$ DBDamageController | SpellDescription$ CARDNAME deals 3 damage to target creature. If you revealed a Dragon card or controlled a Dragon as you cast CARDNAME, CARDNAME deals 3 damage to that creature's controller. | PropagateTgtsToSubAbility$ True | StackDescription$ SpellDescription
- Code: Select all
private static void resolveSubAbilities(final SpellAbility sa, final Game game) {
final AbilitySub abSub = sa.getSubAbility();
if (abSub == null || sa.isWrapper()) {
return;
}
// + UGLY HACK for Draconic Roar + //
if (sa.hasParam("PropagateTgtsToSubAbility")) {
abSub.setTargets(sa.getTargets());
}
// - UGLY HACK for Draconic Roar - //
...
Obviously, this is not the way it's supposed to work when fixed (and it's a pure, ugly hack that might work for this particular scenario but will most likely not be useful for anything else because copying targets from a parent SA to a sub SA is normally a bad idea), but I can't for the life of me figure out how to make it work correctly (and I'm reluctant to commit the ugly half-assed solution).
Does anyone have the incentive to take a fresh look at what's going on there? Trapping getDefinedPlayers in AbilityUtils might be a good starting point (that's the function that is called when the game is trying to identify TargetedController - see e.g. line 820). I tried comparing the chain of calls for the human and for the AI and I see that the thing eventually breaks for the AI but I can't narrow it down to its source. :/ Any help is really welcome here!
The reason I'm so insistent on fixing this is because Draconic Roar is a rather popular (and strong) card in the current formats, and having the AI misplay it becomes noticeable from time to time (and setting it to RemAIDeck is probably a bad idea because generally the AI can properly use the card - including paying the reveal dragon cost and all, it's just that it doesn't resolve correctly because some relevant information is lost elsewhere). :/
Thanks in advance for help!
- Agetian
And haha yep, it sure does 