Triggered Abilities in Ability Factory

[friarsol]

So just out of sheer curiosity I tried experimenting in my local codebase and was able to get Triggered abilities working in AFs. (Well just one of them) It was pretty easy actually, but I don't think we should start doing this that soon. We'd probably be better off converting over any Code blocks (that can) into AFs and creating the next handful of AFs that would be useful.

Some new AFs that I see coming soon:
Discard
Destroy
MakeToken
GainControl

along with adding in All for those applicable (DamageAll, BounceAll, TapAll etc). It's probably better that these are distinct from the current blocks as they would be used differently by the AI.

But the more stuff that gets converted, the more we can improve logic in one spot to help the AI out.

And of course the other SubAbility work for combining abilities that was discussed recently. Rob, were you taking point on the SubAbility stuff? I still have to play clean up on my Phase stuff, and I have a few other decent sized things I wanted to do.

[Sloth]

I will try to add a working AF Destroy.

I'm also pondering where to add abilities like Headstone. Should it be bounce or retrieve or something new (but probably not a new class).

[Hellfish]

Diving headfirst into a MakeToken factory.

EDIT:Well, that was a quick job. Will commit once I get home and convert the rest of the spMakeToken cards.(Acorn Harvest and Carrion Call are converted and tested.

[friarsol]

I'm thinking Headstone would use the Retrieve AF (since Retrieve targets things in the graveyard) along with the IsCurse Parameter for the AI.

Retrieve, Bounce and Fetch are all sister Factories. They all do the same thing (Move from <this zone> to declared zone.) with the starting zone being the primary difference, but changes the way the AI would handle things. Since normally Retrieve is a "good thing" if we set the IsCurse parameter the AI would now target something in an opponents graveyard. The AI for an Retrieve/IsCurse might look like this:

Code: Select all

Loop through cards in Humans Graveyard
Loop through each cards Ability
If Ability's ActivatingZone is the Graveyard, add to list

If list is empty, get best from original list.
else, get best from graveyardActivatingList


[Chris H.]

Diving headfirst into a MakeToken factory.

EDIT:Well, that was a quick job. Will commit once I get home and convert the rest of the spMakeToken cards.(Acorn Harvest and Carrion Call are converted and tested.

`
Thank you, and it was quick.

[slapshot5]

Unless someone has already started it, I will start taking a look at AbilityFactory_GainControl.

I was going to code Willow Satyr today, so this is a logical extension.

-slapshot5

[PhoenixAvenger]

Random thoughts and observations:

- Two more AbilityFactories that I foresee would be useful down the road: an AF_Counterspell (mentioned in passing by Hellfish not long ago, I believe) and an AF_Mana (key gains would be converting mana abilities to Ability_Cost and possibly providing limits to use mana for casting/playing abilities of defined ValidCards, e.g. Mishra's Workshop and Eldrazi Temple. Might depend on how malleable the ManaPool code is, though.)

- For Bounce|Destination$Exile, an optional Duration$ parameter should be added (for stuff like Turn to Mist and Momentary Blink), to account for how long a card should remain in exile. Possibilities would include: Instantaneous, UntilNextEOT, LeavesPlay, None; this would assume None unless otherwise defined. As soon as slapshot5 gets the duration code ironed out in AF_GainControl, it should be fairly easy to convert to AF_Bounce - the only thing that would need to be added is a way for the exiled card to remember what exiled it, and for how long, until/unless it leaves the exile zone.

- Sloth, how difficult would it be to add the NoRegen$True parameter into AF_DealDamage? Incinerate and its pals have been hanging out in the aether for far too long...

- Hellfish, your image selection constructor of AF_Token was rather clever, but it falls short where keywords become involved - namely, for tokens that would otherwise be identical except for one having a keyword the others don't. (For example, Ant Queen tokens and Trigon of Infestation tokens had different pictures before the AB$Token conversion.) There should be an optional TokenImage$ parameter to handle these cases; leaving it blank would default to your constructor.

- Finally, as you guys set your sights on expanding AbilityFactory and replacing the old keywords, see if you can get enters-the-battlefield capability added into AbilityFactory somewhere down the line. (Unless that was what Sol was referring to in the first place...)

[Sloth]

- Sloth, how difficult would it be to add the NoRegen$True parameter into AF_DealDamage? Incinerate and its pals have been hanging out in the aether for far too long...

This can be done by adding the keyword: "CARDNAME can't be regenerated.". The keyword can be given by a subability. Because pumping is not supported by doDrawback at the moment, I think we should wait for subabilities via ability factory.

- For Bounce|Destination$Exile, an optional Duration$ parameter should be added (for stuff like Turn to Mist and Momentary Blink), to account for how long a card should remain in exile. Possibilities would include: Instantaneous, UntilNextEOT, LeavesPlay, None; this would assume None unless otherwise defined. As soon as slapshot5 gets the duration code ironed out in AF_GainControl, it should be fairly easy to convert to AF_Bounce - the only thing that would need to be added is a way for the exiled card to remember what exiled it, and for how long, until/unless it leaves the exile zone.

These effects work quite differently depending on the "Duration". "UntilNextEOT" would create a delayed triggered ability while "Instantaneous" would not. Of course it's all doable but it's a lot work for only a small number of cards the AI would not be able to use at the moment. (On the other hand some of the cards are quite interesting and fun).

[Hellfish]

- Hellfish, your image selection constructor of AF_Token was rather clever, but it falls short where keywords become involved - namely, for tokens that would otherwise be identical except for one having a keyword the others don't. (For example, Ant Queen tokens and Trigon of Infestation tokens had different pictures before the AB$Token conversion.) There should be an optional TokenImage$ parameter to handle these cases; leaving it blank would default to your constructor.

Done,though I was hoping I wouldn't have to do that. In fact, things seem a little inconsistent on that front. Trigon of Infestation tokens are referenced as "<Color> <P> <T> <Name> <Keywords>" because they have Infect while Rakka Mar tokens are referenced as "<Color> <P> <T> <Name>" only, even though they have Haste. Maybe having a standard of "<Color> <P> <T> <Name> <Non-HIDDEN keywords separated by space>" would be better. AFAIK that wouldn't require the TokenImage parameter I now added.

EDIT:No that wouldn't work for Sound the Call tokens, now that I think about it. Dang it.

[friarsol]

I already have AF_Mana slated as an Issue and have been working on it. It's much more complicated than it seems and will take some time to work out the kinks. The ManaPool payment code probably needs a bit more work to work with Restrictions, but I did make some progress the last time I was in there.

Counter (not just spells, but abilities too) we had mentioned at some point in earlier threads. And definitely should be on the list for conversion.

Oh and Phoenix, the triggered ability that I handled was enters the battlefield, but as I said at the start of the thread, I don't think we should do this yet. In case you are curious, Radiant's Dragoons was my sample card. It isn't that hard to get working, but we definitely have some more work before we can implement it.

[friarsol]

Diving headfirst into a MakeToken factory.

EDIT:Well, that was a quick job. Will commit once I get home and convert the rest of the spMakeToken cards.(Acorn Harvest and Carrion Call are converted and tested.

Can I ask why you put all the token assignments inside the AbilityFactory class? Since you are creating an object for AbilityFactory_Token why not just send in mapParams and the host card and assign the member variables in a constructor.

This whole block:

Code: Select all

if(!mapParams.get("TokenAmount").matches("[0-9][0-9]?")) //It's an X-value.
   numTokens = getHostCard().getSVar(mapParams.get("TokenAmount"));
else
   numTokens = mapParams.get("TokenAmount");

if(!mapParams.get("TokenPower").matches("[0-9][0-9]?"))
   numPower = getHostCard().getSVar(mapParams.get("TokenPower"));
else
   numPower = mapParams.get("TokenPower");

if(!mapParams.get("TokenToughness").matches("[0-9][0-9]?"))
   numToughness = getHostCard().getSVar(mapParams.get("TokenToughness"));
else
   numToughness = mapParams.get("TokenToughness");

if(mapParams.containsKey("TokenKeywords")) {
   keywords = mapParams.get("TokenKeywords").split("<>");
}
else {
   keywords = new String[0];
}

if(mapParams.containsKey("TokenImage")) {
   image = mapParams.get("TokenImage");
}
else {
   image = "";
}


Could just be straight assigned to the member variables.

.

And the constructor can just grab the variables that wouldn't appear as SVars instead of at the top of Spell/Ability creation. This way you only have to do everything once.

Code: Select all

AF = af;
HashMap<String,String> mapParams = AF.getMapParams()
tokenName = mapParams.get("TokenName");
tokenTypes = mapParams.get("TokenTypes").split(",");
tokenOwner = mapParams.get("TokenOwner");
(etc..)


[Hellfish]

All valid points which can be chalked up to this being my first foray into ability factories. I will address em right now

[friarsol]

All valid points which can be chalked up to this being my first foray into ability factories. I will address em right now

Yep. I figured it was mostly that.

I'm not trying to dissuade people from doing them, just trying to keep that file as clean as possible so it's clear what is happening. The new ones have been coming together well, and the more people who have made them the more people can do a more complex AF in the future when we group other things together.

[friarsol]

I just remembered a few other AFs that can be done.

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.

RevealMove. RevealMove can really do a lot more things and I'm not certain how the AI would handle the complexity that this AF could be. Basically it would be for abilities that Reveal cards from the top of your library and move either some set valid card type to a set zone.

Cards that fit this mould are things like Beast Hunt or Hermit Druid or Call of the Wild. A few other cards that may not be as obvious are Treasure Hunt or Mind Funeral.

Required parameters would be things like Type you are searching for, Number of cards you are searching for, Zone found cards goes to, Zone the rest of the cards go to, amount of cards to reveal (or -1 if you go until you find like in Hermit Druid's case).

There are lots of different variations of this, so we could start with the most basic variety and expand from there.

[Rob Cashwalker]

I haven't been in Forge Dev mode nearly as much the past couple weeks, this weekend especially, so I'm just getting to reading through all this now.

Rob, were you taking point on the SubAbility stuff?

I haven't done anything with it yet. I'll start playing with it, though.

I had wanted to continue the groundwork for sets, but the next step for that is revising the python script to sync all the cards, which I'm not keen on.

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?