Collectible Card Game Headquarters

I can do it for you with the reference client. I'm merging trunk into my own branch without trouble right now.

Agetian wrote:@ Chris: Yeah, basically it's too far into coding already to be lost. I can try merging one revision by one though, see how that goes.

- Agetian

 
One of Max's commit logs mentioned a new Python script that would make the changes to your local copy. This might allow you to run the script to update your local card files and they would then magically match the ones on the SVN?

You might want to wait on a response from Max as if I remember correctly you might be able to save yourself a lot of work.

I'm doing the merge in SplitCards/ right now, but it's true that doing the change locally and then applying some "--record-only" fixups to straighten out the mergeinfo metadata might be faster. If you're not in a hurry, though, it looks like this merge will complete in a couple hours.

@ myk: Thanks a lot for help! I'm not in a hurry at all, so feel free to complete the process whenever it's ready!
And yeah, true, it would have otherwise probably been a good idea to use the script to mirror the changes in trunk, I didn't think of that.

- Agetian

The assault//battery script (with new setinfo):

Code: Select all

Name:Assault
ManaCost:R
AlternateMode: Split
Types:Sorcery
A:SP$ DealDamage | Cost$ R | NumDmg$ 2 | ValidTgts$ Creature,Player | SpellDescription$ Assault deals 2 damage to target creature or player.
SetInfo:INV Uncommon
SetInfo:TSB Uncommon
SetInfo:HOP Uncommon
Oracle:Assault deals 2 damage to target creature or player.

ALTERNATE

Name:Battery
ManaCost:3 G
Types:Sorcery
A:SP$ Token | Cost$ 3 G | TokenAmount$ 1 | TokenName$ Elephant| TokenTypes$ Creature,Elephant| TokenOwner$ You | TokenColors$ Green | TokenPower$ 3 | TokenToughness$ 3 | TokenImage$ g 3 3 elephant | SpellDescription$ Put a 3/3 green Elephant creature token onto the battlefield.
Oracle:Put a 3/3 green Elephant creature token onto the battlefield.
End


Max mtg wrote:The assault//battery script (with new setinfo):
...

Thanks, Max! That'll come in handy! I've added it to the SplitCards branch.

- Agetian

merge is complete. you might still have to update the res/cardsfolder/* directories one by one, though.

Ok, thanks a lot for assistance, myk!

- Agetian

Ok, I guess that the next major task in coding split cards is adding support for rules 708.5 and 708.6. I guess this mostly has to do with the converted mana cost (CMC) and the color of split cards - as such, something will have to be done with getCMC and possibly other methods, as well as (some?) of their callers. My original idea for updating getCMC was as follows:

I thought of overloading getCMC in such a fashion that, when it's called the way it is right now, it functions just the way it does right now (so we don't need to go over all the individual calls to reimplement them differently). However, if it takes an extra parameter, depending on its value, it can return either the combined mana cost of both split sides or the mana cost of a particular split card side (so that it can be called twice in succession to get "two answers" for two split sides where necessary). In that case, we may have to only rewrite the calls to getCMC that actually interact with split cards in one way or another. I'm not sure if this is viable enough, but if you have better ideas, I'm open to suggestions! Also, the bigger part of the problem is that I'm not sure how exactly to understand which calls should be jury-rigged to get more than one response and which ones shouldn't... can you please tell me how I should determine which calls to getCMC should actually be able to produce different responses for split cards?

Please let me know what you think about that.
Also, am I correct that a similar mechanism would have to be implemented for the card color (e.g. getColor), or is it basically enough that the card reports its color as the combination of colors on both sides everywhere except on the stack (that's the current behavior)? And also, are there any other characteristics that would have to be recoded or updated in a similar fashion?

- Agetian

There are so many calls for cmc, so i can't say which ones need two answers and which don't.

Color seems to work fine as is - returning combined value.

Agetian wrote:Also, the bigger part of the problem is that I'm not sure how exactly to understand which calls should be jury-rigged to get more than one response and which ones shouldn't... can you please tell me how I should determine which calls to getCMC should actually be able to produce different responses for split cards?

The most important functions are hasProperty in the card class (should behave according to 708.6.) and xCount in CardFactoryUtil when the parameter contains "CardManaCost" (should return the sum of the cmc's).

The more complicated cases can be worked out after merging the branches.

@ Max: Ok, thanks for confirming the getColor thing!

@ Sloth: Thanks for the info! Do you know what would be the easiest test case to check both of the cases you've mentioned? (what cards should be played etc. to see that the functions work as desired)

- Agetian

Agetian wrote:@ Sloth: Thanks for the info! Do you know what would be the easiest test case to check both of the cases you've mentioned? (what cards should be played etc. to see that the functions work as desired)

The common examples are: Dark Confidant (uses xCount) and Isochron Scepter (uses hasProperty).

Agetian wrote:Do you know what would be the easiest test case to check both of the cases you've mentioned? (what cards should be played etc. to see that the functions work as desired)

IIRC, any card that uses cmc<comparator><compare to> property in the targeting uses getCMC in Card.java from hasProperty (eg: Spell Snare uses cmcEQ2). Counterspells with that restriction can be used to test the card on the stack and changeZone ones will test it in other zones.

Augury Adept and Animate Artifact should use CardManaCost from xCount.

One extra card to test could be Disrupting Shoal which checks on resolution of the spell. I don't have the script in front of me, but that might use CardManaCost, but need to get the cmc of the split being played only. We might need to just add a second cmc function in xCount to handle that.

r20098: Implemented the "two answers for CMC" rule (708.6) in Card.hasProperty. CardManaCost check in CardFactoryUtil appears to correctly return the combined CMC already. As such, both Dark Confidant and Isochron Scepter tests pass.

An issue just showed up with the card copied via Isochron Scepter being for some reason thrown onto stack in its full form instead of the chosen half. - the issue is fixed in r20100, but I'm not sure if there are other cases like that which are possible and which are currently not accounted for, please revise. Also, I'm not sure if the solution is actually the best one, maybe it's worth checking for equality of descriptions of spellabilities rather than the equality of spellability objects themselves and see if they start with the same basic text (such that the ability "X" and the ability "X (without paying its mana cost)" and the ability "X (something else)" are all considered equivalent as far as split card setup goes.

- Agetian