Forge version 1.5.49 or 1.6.0

[friarsol]

Next release TBA based on Release Managers availability.

[Agetian]

Ok, guys, I need your help with something. I'm still trying to investigate the issue with the AI not being able to properly resolve Draconic Roar when revealing a dragon from its hand. The problem is that if the AI has a dragon in its hand and it casts Draconic Roar, when it resolves it does not deal 3 damage to the creature's controller. The card works fine for the human player in this case, and it works fine for the AI in all other cases (no dragon / dragon on the battlefield).

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


...and add the following code to AbilityUtils::resolveSubAbilities:

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 - //

        ...


Then the card functions correctly because the game manages to copy the target information from the parent to the subability before this information is lost, and when the game tries to go through the TargetedController identification loop, it is able to pick up the relevant information from the subability for the purpose of identifying the controller of the targeted creature.

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

[friarsol]

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!

I'll take a look (mostly since your hack looks awful ;p )

[Agetian]

Thanks! And haha yep, it sure does

- Agetian

[Agetian]

Here's a test case where the AI casts a Draconic Roar, reveals Dragonlord Atarka and resolves the Roar, but the human player doesn't get the damage (just skip a phase and the AI should cast the spell):

Code: Select all

humanlife=4
ailife=24
activeplayer=ai
activephase=UPKEEP
humancardsinhand=Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Dragonlord Atarka
humancardsinlibrary=Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain
humancardsingraveyard=Abbey Gargoyles;Aboroth;Abattoir Ghoul;Go for the Throat;Abattoir Ghoul;Mountain;Mountain
humancardsinplay=Mountain;Mountain;Abattoir Ghoul|SummonSick:True
humancardsinexile=
humancardsincommand=
aicardsinhand=Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Dragonlord Atarka;Draconic Roar
aicardsinlibrary=Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain;Mountain
aicardsingraveyard=Foul-Tongue Invocation;Mountain;Forest;Mountain;Foul-Tongue Invocation;Draconic Roar;Dragonlord Atarka;Draconic Roar
aicardsinplay=Swamp;Swamp;Mountain;Forest;Mountain
aicardsinexile=
aicardsincommand=


- Agetian

[friarsol]

Ok. I have it fixed locally, basically when a SA Stack Instance gets injected back into a SA during resolution, I'm now setting the Parent explicitly. Also, I changed Draconic Roar to be using ParentTargetedController although I'm not sure if that matters or not.

I'll play a few random games and keep an eye on the targeting to see if anything looks weird, then push it out. We should keep an eye on this, but I think that change should be ok.

[Agetian]

Ok. I have it fixed locally, basically when a SA Stack Instance gets injected back into a SA during resolution, I'm now setting the Parent explicitly. Also, I changed Draconic Roar to be using ParentTargetedController although I'm not sure if that matters or not.

I'll play a few random games and keep an eye on the targeting to see if anything looks weird, then push it out. We should keep an eye on this, but I think that change should be ok.

Oh, interesting! Thanks a lot for help! Here's hoping your solution is going to work great!

By the way, I tried changing TargetedController to ParentTargetedController before but it did not change the situation on its own, although I agree it's a better idea to keep it on ParentTargetedController to make it more explicit (now that the other part of the problem is solved, too).

- Agetian

[drdev]

As a heads up, I just committed a fix for a long standing peeve of mine which is that two, three, and four color decks were not displaying their colors in the correct order. I finally came up with a reliable and minimal performance impact way to accomplish this by creating a mapping of every color combination (as a byte) to an array of ManaCostShards in the correct order.

Let me know if you have any questions or concerns about this change. I've updated both the desktop and mobile games to show color sets in the correct order. This will be even more important with the introduction of Planar Conquest, which shows color sets in a few places and encourages multicolor decks.

Thanks.
-Dan

[Marek14]

Which ordering do you use for wedges?

[drdev]

Which ordering do you use for wedges?

I used the color order described here (ignoring the typo in the 4 color costs):

http://www.mtgsalvation.com/forums/magi ... mbinations

I did just read that the wedge color order has been tweaked from BGW to WBG, so I can change that if people prefer.

http://www.mtgsalvation.com/forums/magi ... the-future

[slyfox7777777]

Does anyone know what the correct naming convention is for split cards in the rankings.txt for draft? They're messed up right now and I'm trying to go through and fix them, but I can't figure out what the right syntax is.

[friarsol]

Didn't I fix that? The generated name was looking for two spaces instead of one space.

[slyfox7777777]

Hmm, I guess you did. I wonder why I thought it was still messed up.
It definitely works for DGM now, but some of the names from the older sets still have two spaces, like "fire Ice," so I guess I don't understand why it's only working for the more recent sets, that is unless you just went in there and did it manually.

Edit: I might have been using a different snapshot, probably not very professional. Take this for a grain of salt. I'm sure it's all resolved.
Re-edit: Okay, I got the latest snapshot, and it does look like older split cards still have the same problem.

[slyfox7777777]

I will probably be posting a ratings file with this and a couple of other fixes fairly soon.
At the very least, it should have:
VMA ratings
TPR ratings
Fixes to the remaining split cards
Fixes to TSB ratings
Fixes to BFZ and OTG expeditions

[friarsol]

Hmm, I guess you did. I wonder why I thought it was still messed up.
It definitely works for DGM now, but some of the names from the older sets still have two spaces, like "fire Ice," so I guess I don't understand why it's only working for the more recent sets, that is unless you just went in there and did it manually.

Edit: I might have been using a different snapshot, probably not very professional. Take this for a grain of salt. I'm sure it's all resolved.
Re-edit: Okay, I got the latest snapshot, and it does look like older split cards still have the same problem.

Ah. Probably the old rankings set blocks realized this problem and adjusted the names appropriately, but the DGM rankings didn't so they didn't work. So when I fixed the problem, it broke the old things. I'll update the file when you post the new rankings file...