Page 1 of 1

AI availability blocks -- questions and discussion

PostPosted: 03 Feb 2017, 13:54
by Splinterverse
I want to have a deeper understanding of how the AI availability blocks work so that I might use them to their fullest capability.

I grepped all of the cards in the CW to see which AI Availability blocks are in use.

These are pretty clear -- you use them to represent other players' turns within which the AI can play the card:
    <AI_AVAILABILITY step="begin_combat" turn="their_turn" />
    <AI_AVAILABILITY step="declare_attackers" turn="their_turn" />
    <AI_AVAILABILITY step="end_of_turn" turn="their_turn" />

There are others that appear to be similar, but have window_step instead of step and they have type="window". What is the difference?
    <AI_AVAILABILITY window_step="upkeep" window_turn="their_turn" type="window" />
    <AI_AVAILABILITY window_step="main_1" window_turn="their_turn" />
    <AI_AVAILABILITY window_step="main_1" window_turn="their_turn" type="window" />
    <AI_AVAILABILITY window_step="begin_combat" window_turn="their_turn" type="window" />
    <AI_AVAILABILITY window_step="declare_attackers" window_turn="their_turn" type="window" />
    <AI_AVAILABILITY window_step="declare_blockers" window_turn="their_turn" type="window" />
    <AI_AVAILABILITY window_step="main_2" window_turn="their_turn" type="window" />

There are some that appear to be used for the step regardless of whose turn it is:
    <AI_AVAILABILITY step="declare_blockers" />
    <AI_AVAILABILITY step="end_of_turn" />

There are some that appear to be used for the step regardless of whose turn it is, but these are window_step instead of step:
    <AI_AVAILABILITY window_step="untap" />
    <AI_AVAILABILITY window_step="untap" type="window" />
    <AI_AVAILABILITY window_step="upkeep" />
    <AI_AVAILABILITY window_step="upkeep" type="window" />
    <AI_AVAILABILITY window_step="main" type="window" />
    <AI_AVAILABILITY window_step="main1" type="window" />
    <AI_AVAILABILITY window_step="begin_combat" type="window" />
    <AI_AVAILABILITY window_step="declare_attackers" type="window" />
    <AI_AVAILABILITY window_step="declare_blockers" type="window" />
    <AI_AVAILABILITY window_step="end_of_turn" type="window" />

There appears to be one that is specific to "my turn" (AI's turn) but does not have window_step:
    <AI_AVAILABILITY step="main_1" turn="my_turn" />

These are the "window" versions for "my turn":
    <AI_AVAILABILITY window_step="upkeep" window_turn="my_turn" type="window" />
    <AI_AVAILABILITY window_step="main_1" window_turn="my_turn" type="window" />
    <AI_AVAILABILITY window_step="main_1" window_turn="my_turn" type="window" />
    <AI_AVAILABILITY window_step="begin_combat" window_turn="my_turn" type="window" />
    <AI_AVAILABILITY window_step="declare_attackers" window_turn="my_turn" type="window" />
    <AI_AVAILABILITY window_step="declare_blockers" window_turn="my_turn" type="window" />
    <AI_AVAILABILITY window_step="main_2" window_turn="my_turn" type="window" />
    <AI_AVAILABILITY window_step="end_of_turn" window_turn="my_turn" type="window" />

These have window_in_combat="1" -- what does that signify beyond the normal tags?
    <AI_AVAILABILITY window_step="declare_attackers" type="window" window_in_combat="1" />
    <AI_AVAILABILITY window_step="declare_attackers" window_turn="my_turn" type="window" window_in_combat="1" />
    <AI_AVAILABILITY window_step="declare_blockers" type="window" window_in_combat="1" />
    <AI_AVAILABILITY window_step="declare_blockers" window_in_combat="1" />
    <AI_AVAILABILITY window_step="declare_blockers" window_in_combat="1" type="window" />
    <AI_AVAILABILITY window_step="declare_blockers" window_turn="my_turn" type="window" window_in_combat="1" />

This one has blocking_or_blocked="1" -- does this mean that it is only available if it is the declar_blockers step and the creature is blocking or blocked?
    <AI_AVAILABILITY step="declare_blockers" blocking_or_blocked="1" />

These have restriction in their tags. How do these work?
    <AI_AVAILABILITY type="restriction" restriction_characteristic="CHARACTERISTIC_FIRST_STRIKE" />
    <AI_AVAILABILITY type="restriction" restriction_characteristic="CHARACTERISTIC_HASTE" />
    <AI_AVAILABILITY type="restriction" restriction_characteristic="CHARACTERISTIC_HEXPROOF" />
    <AI_AVAILABILITY type="restriction" restriction_characteristic="CHARACTERISTIC_INDEASTRUCTIBLE" />
    <AI_AVAILABILITY type="restriction" restriction_characteristic="CHARACTERISTIC_TRAMPLE" />
    <AI_AVAILABILITY type="restriction" restriction_type="equip" />
    <AI_AVAILABILITY type="restriction" restriction_type="no_regeneration_shield" />

These have in_response but I'm confused by response_source and response_target (as well as in_response_dangerous) -- how do these work?
    <AI_AVAILABILITY type="in_response" />
    <AI_AVAILABILITY type="in_response" response_source="1" />
    <AI_AVAILABILITY type="in_response" response_source="1" response_target="1" />
    <AI_AVAILABILITY type="in_response" response_target="1" />
    <AI_AVAILABILITY type="in_response_dangerous" />

Re: AI availability blocks -- questions and discussion

PostPosted: 03 Feb 2017, 23:42
by thefiremind
Splinterverse wrote:There are others that appear to be similar, but have window_step instead of step and they have type="window". What is the difference?
You should look at the official cards just to be sure, but I think that either they are equivalent, or only window_step is right while the other one is a leftover from the older DotP syntax.
I don't know what changes when including type="window" (if anything changes at all).

Splinterverse wrote:These have window_in_combat="1" -- what does that signify beyond the normal tags?
The AI should activate the ability only when the creature with that ability is in combat. At least that's what I would guess.

Splinterverse wrote:This one has blocking_or_blocked="1" -- does this mean that it is only available if it is the declar_blockers step and the creature is blocking or blocked?
I think so.

Splinterverse wrote:These have restriction in their tags. How do these work?
By looking at the regeneration one, I assume it means: don't use this ability if the target already has what the ability would grant. For the regeneration, it avoids regenerating again if the creature already has a "regeneration shield" on it.

Splinterverse wrote:These have in_response but I'm confused by response_source and response_target (as well as in_response_dangerous) -- how do these work?
These always confuse me as well. I look at how the official cards use them, I collect my thoughts, then the next time I can't remember the conclusion I came up with. #-o I'm about to collect my thoughts again, but be aware that nothing is for sure.
  • response_source probably means that the AI should activate the ability in response to something targeting the source of the ability (for example, you activate your Prodigal Sorcerer one last time before he dies for a Shock).
  • response_target probably means that you should activate the ability or cast the spell targeting something that has just been targeted by something else (for example, you Giant Growth your creature so that the Shock doesn't kill it). If you notice, spells have response_target but I don't remember them ever having response_source, that's what makes me come to this conclusion.
  • response_dangerous probably means that you should activate the ability in response to something that harms you or your permanents. It was largely used in DotP2013, I didn't even realize it was still used in DotP2014.
What I really don't know is if having just 1 block with both response_source and response_target is equivalent to having 2 separated blocks with 1 attribute each. You would think it's not equivalent by looking at the official cards, but they also have repetitions that are clearly useless (2 blocks both with only response_source inside the same ability, for example) so I'm not sure. In my cards I usually assume it's equivalent.

Re: AI availability blocks -- questions and discussion

PostPosted: 04 Feb 2017, 11:20
by Splinterverse
Thanks for the info, TFM. This is very helpful.

Some of these might not actually be correct tags. I grepped everything, so it's possible that some of them are incorrect. Probably before I use one that I think might be wrong, I'll grep to see how many files use it.