Forge version 1.5.49 or 1.6.0
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
Re: Forge version 1.5.49 or 1.6.0
by Agetian » 30 Jan 2016, 18:04
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:
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
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
- Agetian
- Programmer
- Posts: 3474
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 563 times
Re: Forge version 1.5.49 or 1.6.0
by friarsol » 30 Jan 2016, 18:43
I'll take a look (mostly since your hack looks awful ;p )Agetian wrote: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!
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Forge version 1.5.49 or 1.6.0
by Agetian » 30 Jan 2016, 19:20
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
- Programmer
- Posts: 3474
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 563 times
Re: Forge version 1.5.49 or 1.6.0
by friarsol » 30 Jan 2016, 20:24
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.
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.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Forge version 1.5.49 or 1.6.0
by Agetian » 30 Jan 2016, 20:32
Oh, interesting! Thanks a lot for help! Here's hoping your solution is going to work great!friarsol wrote: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.
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
- Agetian
- Programmer
- Posts: 3474
- Joined: 14 Mar 2011, 05:58
- Has thanked: 677 times
- Been thanked: 563 times
Re: Forge version 1.5.49 or 1.6.0
by drdev » 07 Feb 2016, 21:41
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
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
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Forge version 1.5.49 or 1.6.0
by Marek14 » 08 Feb 2016, 08:43
Which ordering do you use for wedges?
Re: Forge version 1.5.49 or 1.6.0
by drdev » 08 Feb 2016, 15:18
I used the color order described here (ignoring the typo in the 4 color costs):Marek14 wrote:Which ordering do you use for wedges?
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
- drdev
- Programmer
- Posts: 1958
- Joined: 27 Jul 2013, 02:07
- Has thanked: 189 times
- Been thanked: 565 times
Re: Forge version 1.5.49 or 1.6.0
by slyfox7777777 » 09 Feb 2016, 01:00
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.
- slyfox7777777
- Posts: 23
- Joined: 26 Mar 2014, 18:26
- Has thanked: 1 time
- Been thanked: 0 time
Re: Forge version 1.5.49 or 1.6.0
by friarsol » 09 Feb 2016, 02:26
Didn't I fix that? The generated name was looking for two spaces instead of one space.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
Re: Forge version 1.5.49 or 1.6.0
by slyfox7777777 » 09 Feb 2016, 02:39
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.
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
- Posts: 23
- Joined: 26 Mar 2014, 18:26
- Has thanked: 1 time
- Been thanked: 0 time
Re: Forge version 1.5.49 or 1.6.0
by slyfox7777777 » 09 Feb 2016, 02:53
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
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
- slyfox7777777
- Posts: 23
- Joined: 26 Mar 2014, 18:26
- Has thanked: 1 time
- Been thanked: 0 time
Re: Forge version 1.5.49 or 1.6.0
by friarsol » 09 Feb 2016, 04:36
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...slyfox7777777 wrote: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.
- friarsol
- Global Moderator
- Posts: 7593
- Joined: 15 May 2010, 04:20
- Has thanked: 243 times
- Been thanked: 965 times
22 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 39 guests