This was a bug reported by a guy in the forum: Dakr Depths produced a token every time it hit the graveyard, even it it had a counter on it. ^^
[card]
name=Dark Depths
auto=counter(0/0,10,Ice)
auto={3}:(counter(0/0,-1,Ice) all(this) && bury all(dark depths[-counter{0/0.1.Ice}])
auto=@movedTo(mygraveyard) from(dark depths[-counter{0/0.1.Ice}]|myBattlefield):token(Marit Lage,legendary creature avatar, 20/20,flying,indestructible,black)
text=Dark Depths enters the battlefield with ten ice counters on it. -- {3}: Remove an ice counter from Dark Depths. -- When Dark Depths has no ice counters on it, sacrifice it. If you do, put a legendary 20/20 black Avatar creature token with flying and "This creature is indestructible" named Marit Lage onto the battlefield.
type=Legendary Snow Land
[/card]
1. General's Kabuto
2. Lightning Greaves
3. Neurok Stealthsuit
4. Whispersilk Cloak
5. Darksteel Garrison
6. Shield of Kaldra
Fixed following cards according MTG rules:
1. Lord of the Pit
2. That Which Was Taken
3. Vigor
4. Worldslayer
5. Yomiji, Who Bars the Way
Other fixed cards:
1. Magebane Armor
2. Talon of Pain
Note this particular aspect of the "becomes" ability was not broken prior to the fix for 559. This is a sanity check as it has nothing to do with color change. but tests ability changes due to "becomes" ability.
Issue: 559
This one was a bit of a doozy to fix correctly, but the actual fix ended up being fairly simple - the upshot is that TargetAbility never checked for whether an extra cost needed setting prior doing a target selection. While at it, I discovered and fixed another bug: if you're in the middle of an extra cost choice (like sacrifice, for instance) and hit the next phase button, the game would let you proceed, and then hang in an endless loop.
While at it, did a little cleanup/refactoring around GameObserver's waitForExtraPayment - any time a bool has something that sounds like a verb, it probably deserves to be a function. Now it is. (I needed to refactor it anyway, as I reused that code for the next phase hang.)
Note that after this fix, I had to patch two test cases (siege_gang_commander.txt & seismic_assault.txt) - since I've change the selection order (ie a target ability with a sacrifice cost requires the cost to be paid up front before picking the target), this means that tests involving targeting & sacrifices need to switch the order of the cards to pass.
the tag "other " vs tag " other"
using "other " in target choosers will always work, however more often then not using " other" at the end of a line would produce weird effects, this was brought to my attention in a bug report by KF1, i moved all the " other" from outside target chooser into the actual target lines, as this always produces correct results in code, i imagine the tag at end of line was added before "other " was intruduced into targetchooser.
i will leave support for using " other" in code, however, i ask that we try not to use this code unless for some strange reason the targetchooser "other" doesnt take to the code.
stranger was that i noticed alot of mixed code, as in lord(other blahblah) 1/1 and this version with other tag at end, it was very inconsistent aside from causing weird weird results in game which i was actually able to confirm.
please update your primitive!!! this was ALOT of work.
correct syntax for "other "
lord(other blah)
all(other blah,blah,blah)
damage:1 target(other blah)
target(other *|somewhere)
notice its always first followed by a space. you only need one instence "other " in a targetchooser.
