Words that Cards.txt recognizes

[DennisBergkamp]

I'm working on a generic spDestroryTgt([non]color,[non]type). So "Destroy target artifact" no problem - spDestroyTgt(Artifact). "Destroy target nonblack, non artifact creature" - spDestroyTgt(nonblack,nonArtifact,Creature). "Destroy target artifact, enchantment or land" - spDestroyTgt(Artifact,Enchantment,Land).

Would be awesome if you get that working

[mtgrares]

Rob and others, thanks for your effort for adding keywords. It really increases the number of cards that can be easily added. The mana pool works great. I used Dark Ritual yesterday when I using a randomly generated deck and it works great.

[Chris H.]

Keywords recognized as of MTG Forge 07-05-2009 are:

EDIT:

Some changes were recently made to this list. Please view the newer content below:

http://www.slightlymagic.net/forum/viewtopic.php?f=26&t=701&p=17885#p17885

[DennisBergkamp]

I suspect that the string "1, Sacrifice {name} Spellbomb: Draw a card." is not a keyword and could safely replace the "no text" string above it.

Actually, I think this IS a keyword (don't replace it with "no text")

[zerker2000]

Yep... I think that should be modified to be "inPlayCycling:{Cost}" actually, I think the way it works right now is "1:Sacrifice {name} : draw a card"(the cards it's used for/references in program are spellbomb), and I'm pretty sure I have seen other cards with"<cost>, Sacrifice {name}: Draw a card" before.

[Sloth]

You are right zerker, there are a few permanents with "<cost>, Sacrifice {name}: Draw a card".

These are especially easy: Brass Secretary, Heart Warden, Sarcomite Myr & Slinking Skirge.

If you make it a keyword, they could be easily added.

[zerker2000]

So then we Could keyword sacromite myr... what should it be called?

[Chris H.]

I suspect that the string "1, Sacrifice {name} Spellbomb: Draw a card." is not a keyword and could safely replace the "no text" string above it.

Actually, I think this IS a keyword (don't replace it with "no text")

Yep, I tested it with a fake card and was able to use this new keyword.

Thank you, zerker, good job.

[zerker2000]

Well, half a good job... what should the resulting keyword be called?

[Chris H.]

Well, half a good job... what should the resulting keyword be called?

Hmmm, Rob has done a good job on creating and naming keywords. He may have a suggestion.

[Rob Cashwalker]

Well, half a good job... what should the resulting keyword be called?

Hmmm, Rob has done a good job on creating and naming keywords. He may have a suggestion.

Either-
Exclusive to this precise mechanic:
abSacMeDraw:{mana/tap}

Or generic to the permanent ability to draw cards, and parse out a "cost" of "SAC" in the same way the abTgt_Pumps filter "T" from the mana cost:
abDraw {mana/tap/SAC}:NumToDraw
abDrawDiscard {mana/tap/SAC}:NumToDraw:NumToDiscard

[zerker2000]

Here's me again with my crazy parsing ideas: just how hard would it be to hava a generic SpellAbility cost parser that filtered things like mana, tap/tap(typeFilter), sacrifice/sacrifice(typeFilter), removeCounter(name), discard/discard(type), etc.? Then, it would probably be feasible to make a matching Input_PayCosts() that figured out canPlay, Inputed&placed sac/tap "flags" on relevant cards, ran a (slightly modified)Input_PayManaCost, and then when the cost was paid removed counters/executed flags(or on unpaid cleared flags and stop()-ed. Once again, this is mostly me thinking aloud about (what I see as) the optimal cost method.

[Rob Cashwalker]

Here's me again with my crazy parsing ideas: just how hard would it be to hava a generic SpellAbility cost parser that filtered things like mana, tap/tap(typeFilter), sacrifice/sacrifice(typeFilter), removeCounter(name), discard/discard(type), etc.? Then, it would probably be feasible to make a matching Input_PayCosts() that figured out canPlay, Inputed&placed sac/tap "flags" on relevant cards, ran a (slightly modified)Input_PayManaCost, and then when the cost was paid removed counters/executed flags(or on unpaid cleared flags and stop()-ed. Once again, this is mostly me thinking aloud about (what I see as) the optimal cost method.

You've got the right idea, but I'm not sure if it would work with the way the rest of the code is designed - might have to re-write a lot of it.

Yeah, why couldn't the mana cost system just look for "T" in a cost and know to tap the ability source card, or see "SAC" in a cost and know to sac the ability source card. I don't really know.... But the cancel button would have to also untap it (no prob) or unsac it.... Problem! Think about all the issues we have with persist and phantom card copies, and cards not remembering their abilities... not that those issues aren't fixable, and affect other aspects of play.... It's just another can of worms.

Rares programmed a number of samples for us, all we're trying to do is copy them en-Masse taking into account a few additional forms of the mechanic.

Now, I can see some value to making some helper function to filter out the "T" and "SAC", returning booleans directly instead of explicitly coding it for each keyword we come up with that can use those forms of payment. Supporting "SAC" and "SACAC" (Sac A Creature) would open up a few more cards for pumps and other keyworded abilities.

BTW, this is a related topic that I forgot why I started typing it, but it's not worth deleting. -
It sure seems like Input_PayManaCostUtil is where it parses the "tap: add _" and because of that, I was able to easily hack the "ManaPool:_" "keyword" because it had the same number of characters, not that I couldn't make it work with a different number of characters, just less needed to be changed to still make it work. I've considered that it could also look for "pain/tap:_" and it would be able to support the pain lands without explicitly naming them in the source code.

[zerker2000]

But the cancel button would have to also untap it (no prob) or unsac it.... Problem! Think about all the issues we have with persist and phantom card copies, and cards not remembering their abilities... not that those issues aren't fixable, and affect other aspects of play.... It's just another can of worms.

That is why you don't want to be actual tap/sac cards until all costs are paid, simply FLAG them so. In fact, GUI shouldn't display them as already tapped/sacked before costs are paid, simply overlay an arrow/red X showing what will happen when you're done with paying mana.(Then, when costs are resolved, the flags are actually followed. In fact, this could be taken a step further so that lands tapped during mana/Mana Pool content are also flagged/grayed out.)

Supporting "SAC" and "SACAC" (Sac A Creature) would open up a few more cards for pumps and other keyworded abilities.

I think the best way to go would be to have Sac(filter) and Tap(filter), where the filter in the parentheses would be sent to a methodised version of what you're trying to make in SpDestroyTarget

BTW, this is a related topic that I forgot why I started typing it, but it's not worth deleting. -
It sure seems like Input_PayManaCostUtil is where it parses the "tap: add _" and because of that, I was able to easily hack the "ManaPool:_" "keyword" because it had the same number of characters, not that I couldn't make it work with a different number of characters, just less needed to be changed to still make it work. I've considered that it could also look for "pain/tap:_" and it would be able to support the pain lands without explicitly naming them in the source code.

Will you please look at my "Buncha code" post in Developer's corner and comment on / build off that? I think Dennis was going to / thought he did put it in the latest beta, but I couldn't find the prommissed

- Modified mana pool to just use mana with a single click, provided there are no other colors in there (thanks Zerker!).

anywhere .

[frwololo]

Guys, it's always interesting to come to this topic once in a while and see in which direction you go.
Wagic also made the bet of using "keywords" in text files to softcode some cards, and it's clearly made my life easier... in the beginning

I clearly see that Rob's recent changes go in the path of more flexibility. Not only simple keywords, but small chunks of code hat accept parameters, etc...

You might want to keep in mind some of the mistakes I did, to avoid them when it's your turn:
1)most of my code is implicit. This worked well in the beginning, but it is now creating stupid issues. For example, cards that say: target gets +1/+1 until end of turn should have a keyword that looks like "1/1 ueot" rather than simply "1/1"
2)At some point, you will need to use a real parsing mechanism. I don't, and it prevents my parser from growing. In C++, those are called Lex and Yacc, and I'm sure there are equivalents for that in Java.

I come to this thread very often to get inspiration. We have our own thread regarding Wagic's parser, and I'm sure you will find it funny to see how much issues we share with forge: http://wololo.net/forum/viewtopic.php?f=6&t=378