[WIP] Split Cards Support

[Max mtg]

see r20005

[Max mtg]

Next, you have to transform the card into its left or right side as it reaches stack

[Agetian]

@ Max: Thanks a lot for assistance! kk, will get on with the next goal very soon (hopefully tomorrow).

- Agetian

[Agetian]

Ok, the implementation of transformation of the split card into one of its two faces seems to work correctly (r20020). I had to add an extra SA parameter to the script in order for it to work (the left side of the split now has "SplitSide$ LeftSplit" specified, and the right side of the split now has "SplitSide$ RightSplit" specified). Not sure how to do it in a better way, but it works with this setup and seems to work correctly. If the parameter is not present in the script, the game will display an error debug message to System.out and will throw the full split card face onto the stack (I'm not sure if maybe throwing an exception is a better idea?)

As far as I understand, if this part of the implementation works thus far (I mean, the combined face + individual splits thrown onto stack), it's time to deal with the idiosyncrasies of split cards such as the CMC, right? I have a few ideas but I need a consultation:

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?

P.S. Starting with r20022 I revert the state of the split card to the original full face before the card reaches the graveyard. Please let me know if this is correct behavior. Also, in r20023, I added a similar back-transformation for exiling the card, not sure if it can ever be exiled while on stack, so if it can't, feel free to revert or let me know so that I can revert it.

- Agetian

[Max mtg]

Ok, the implementation of transformation of the split card into one of its two faces seems to work correctly (r20020). I had to add an extra SA parameter to the script in order for it to work (the left side of the split now has "SplitSide$ LeftSplit" specified, and the right side of the split now has "SplitSide$ RightSplit" specified). Not sure how to do it in a better way, but it works with this setup and seems to work correctly. If the parameter is not present in the script, the game will display an error debug message to System.out and will throw the full split card face onto the stack (I'm not sure if maybe throwing an exception is a better idea?)
- Agetian

http://svn.slightlymagic.net/websvn/dif ... &peg=20020
You may just search the matching ability on each side of card, and transform into the one that would have it.
As you may have noted, the abilities from each face are copied by reference to the combined face, so that they can be checked for equlality with plain == operator. That won't have you mantain that extra parameter of "SplitSide"

You asked, if a card can be exiled from stack - yes, it's possible (Mindbreak Trap)
I think it's correct to transform card back to 'original' state when it hits any zone other than stack.
Check also that card is transformed back to original when the mana cost payment is cancelled and the card returns to hand

[Agetian]

Umm I'm working on it now and I ran into an issue... - yes, the issue is gone.

- Agetian

[Agetian]

Ok, done and done - the split card is now correctly back-transformed in all known zone movement and cancelation cases except when going to stack.

- Agetian

[Agetian]

r20027: Now, the spell ability parameter SplitSide is no longer required, the spell ability is determined by testing for equality. Also, the NPE related to the process of back-transformation of split cards is fixed. The split card correctly returns to its initial state when moved to graveyard/exile/hand/etc. and when the targeting or mana cost payment is canceled.

- Agetian

[Agetian]

There's one more major series of commits related to full update of all cards in the trunk, what should I do with it? Should I merge it one revision by one so that it can later be reintegrated into trunk one by one or can I merge them all into one large commit? Not sure what would be the best option given that earlier I had problems merging everything at once into SplitCards...

- Agetian

[Chris H.]

Should I merge it one revision by one so that it can later be reintegrated into trunk one by one

 
I plan to do it this way myself.

[Agetian]

@ Chris: Thanks a lot for help, Chris! I'd appreciate that!

- Agetian

[Chris H.]

@ Chris: Thanks a lot for help, Chris! I'd appreciate that!

- Agetian

 
I just finished updating and am now at the head revision 20070. I am just a point and click sort of guy and updated using Eclipse.

There may be a way to update one rev at a time using a terminal command/script that increments the rev number.

[Agetian]

@ Chris: updating is not a problem (just within trunk) but it's a major problem for merging (and, I assume, reintegrating later)... would it be possible for you to assist me in merging those revisions into SplitCards or would you like me to try and proceed on my own? I'm afraid I can ruin something, either now or in the long run.

- Agetian

[Chris H.]

@ Chris: updating is not a problem (just within trunk) but it's a major problem for merging (and, I assume, reintegrating later)... would it be possible for you to assist me in merging those revisions into SplitCards or would you like me to try and proceed on my own? I'm afraid I can ruin something, either now or in the long run.

- Agetian

 
I would be happy to help but I am afraid that my knowledge level is fairly low. I have not done any trunk branch work in the past as I try to keep my local copy pristine so I can do the beta and snapshot builds without too many conflicts.

It looks like you have gotten up to r20045 and resolved any conflicts so as to keep your own code mods.

I would assume that the later revs are dealing only with the card files but I guess that you have a few split cards as part of your branch and are concerned about resolving these conflicts in the later rev numbers?

I can understand that you want to be careful in order not to have to start up a new branch again and lose your existing branch work.

[Agetian]

@ 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