Triggered Abilities in Ability Factory

[friarsol]

I'm curious how exactly the triggered ability you made worked... Is it like the Whenever keyword sort of triggered ability? If so, what triggers it?

To ease Rob's curiosity here's the code I put together to get this to work.

Two key pieces missing from this code block are AbilityFactory's API call into the Trigger (which will return a null for the SA) and in CardFactory, before anything is done to the SA, checking if it's null and continue-ing the loop if so. Both of these are needed to prevent Null Pointer Errors.

Now onto the fun:

Code: Select all

public static SpellAbility createTriggerGainLife(final AbilityFactory AF){
   if (!AF.getMapParams().containsKey("Trigger"))
      return null;
   
   String sTrigger = AF.getMapParams().get("Trigger");
   
   final Card host = AF.getHostCard();
   
   final SpellAbility trGainLife = new Ability(host, "0"){
      private static final long serialVersionUID = 6631124959690157874L;
      
      final AbilityFactory af = AF;
      final HashMap<String,String> params = af.getMapParams();
   
      @Override
      public String getStackDescription(){
      // when getStackDesc is called, just build exactly what is happening
          StringBuilder sb = new StringBuilder();
          String name = host.getName();
          int amount = calculateAmount(host, params.get("LifeAmount"), this);
          String player = "You gain ";
          if (af.getAbTgt() != null)
             player = getTargetPlayer() + " gains ";
          sb.append(name).append(" - ").append(player).append(amount).append(" life.");

          return sb.toString();
      }
      
      @Override
      public void resolve() {
         int amount = calculateAmount(host, params.get("LifeAmount"), this);
         gainLifeResolve(af, this, amount);
      }
   };
   
   Command trAbility = new Command() {
      private static final long serialVersionUID = -1537994957313929513L;
      
      public void execute() {
         trGainLife.setActivatingPlayer(host.getController());
         AllZone.Stack.add(trGainLife);
      }
   };
   
   if (sTrigger.equals("EntersBattlefield"))
      host.addComesIntoPlayCommand(trAbility);
   
   return null;
}



The card sample I was using was Radiant's Dragoons

Code: Select all

Name:Radiant's Dragoons
ManaCost:3 W
Types:Creature Human Soldier
Text:When Radiant's Dragoons enters the battlefield, you gain 5 life.
PT:2/5
K:Echo:3 W
A:TR$GainLife|Trigger$EntersBattlefield|LifeAmount$5
SVar:Rarity:Uncommon
SVar:Picture:http://www.wizards.com/global/images/magic/general/radiants_dragoons.jpg
End


This way of handling limits the trigger for things the card does. "When this enters the battlefield" "When this leaves the battlefield" for however many of these CommandLists we have or can create.

It wouldn't be as global as some of things that Whenever does "When <type> enters the battlefield" but it can handle many of the simpler methods that take up space in CardFactories.

I can put the Python script back into my list of things to do. I've mostly been flagging down bugs from Phase and Targeting work, but it'd be good to stop looking at the same pieces of code for a bit.

[Sloth]

It wouldn't be as global as some of things that Whenever does "When <type> enters the battlefield" but it can handle many of the simpler methods that take up space in CardFactories.

Well, EntersBattlefield alone would enable about a hundred new cards and all etb keywords as well as some whenever keyword cards could be converted. It would be quite an improvement.

[Sloth]

Cheat (or whatever other name we want to use) this would be for cards in your hand that are cheated into play. This is for cards like Sneak Attack or Elvish Piper.

I'm not a native speaker, but I suggest "Deploy" for these abilities (like in Surprise Deployment).

[Chris H.]

It wouldn't be as global as some of things that Whenever does "When <type> enters the battlefield" but it can handle many of the simpler methods that take up space in CardFactories.

Well, EntersBattlefield alone would enable about a hundred new cards and all etb keywords as well as some whenever keyword cards could be converted. It would be quite an improvement.

`
This is starting to look very interesting. It would be nice to add the etb and ltb variants to the new AF's.

[slapshot5]

I'm not a native speaker, but I suggest "Deploy" for these abilities (like in Surprise Deployment).

I think that's as good a name as any.
-slapshot5

[Rob Cashwalker]

This way of handling limits the trigger for things the card does. "When this enters the battlefield" "When this leaves the battlefield" for however many of these CommandLists we have or can create.

It wouldn't be as global as some of things that Whenever does "When <type> enters the battlefield" but it can handle many of the simpler methods that take up space in CardFactories.

I don't think handling "EntersTheBattlefield" or "LeavesTheBattlefield" individually for each AF is a good idea. I see "TriggeredAbility" as the base keyword, which then gets the actual Command from the AF, sorta like my theory of the SubAbility...

[friarsol]

This way of handling limits the trigger for things the card does. "When this enters the battlefield" "When this leaves the battlefield" for however many of these CommandLists we have or can create.

It wouldn't be as global as some of things that Whenever does "When <type> enters the battlefield" but it can handle many of the simpler methods that take up space in CardFactories.

I don't think handling "EntersTheBattlefield" or "LeavesTheBattlefield" individually for each AF is a good idea. I see "TriggeredAbility" as the base keyword, which then gets the actual Command from the AF, sorta like my theory of the SubAbility...

.
I have strongly stated we should not do this now. This was mostly an experiment to see if I could do it and what it would take. There wasn't any major foresight, just experimentation. Once SubAbility is ready it probably would be easier to handle Triggers as a SubAbility.

I think we shouldn't try to rush every interesting idea through and make sure it makes sense before we get there. Another reason why I didn't want this done yet, was Ability_Trigger currently is a command, where it should be inheriting from Ability. I have this listed as an Issue for me right now, but I don't know when I'll be able to get around to it.

[zerker2000]

Is SubAbility is intended to be an implementation of "effects"(MTG rules sense)?
If so, shouldn't they be called such?