The question seems really, really silly, but I'll ask it anyway: "If an ability’s requirements are not met, it cannot be added to the ability queue."

So what defines a requirement?

Ensnare should be an easy one: " At the end of the Activation Phase, if you are tractored, you may choose 1 ship in your (mobile) arc at range 0-1. Transfer 1 tractor token to it.

It's really obvious that you need to at the very least be tractored to use the ability. Do you also need to measure the range of a ship before adding to the ability queue, however? If not, this actually changes a bunch of preconceptions that my Facebook group just had.

If a requirement is defined as something that is in an "IF X then Y" clause, then this could mean that combos such as Ketsu and Old Teroch still works. Old Teroch could add his ability to the queue, knowing that he is only allowed to measure to any number of target once his ability is reached in the queue.

This FAQ needs a lot more concrete examples, I fear

I think the best way to look at what a conditional requirement would be this:

If the ability were to trigger and resolve straight away, would you meet all the conditions in the ability? in the case of Old T you need to have the same target at R1 both when the ability triggers and when it resolves.

having said that FFG's genuine attempt to clarify multiple triggered effects does need some clarification work, and they probably need to find a group of playtesters to stress test their rules updates before releasing them to avoid these sorts of questions coming up everytime a new rules update is released.

So it’s like a ‘spidey sense’. I have to prove that ships are in range before I can perform the action and see if they are in range.

Three "tiers" of possibilities:

1. Strictly "if X..." abilities are requirements. Ensnare or Anakin can't fire unless their "if" clause is met when they're put into the queue, even if a simultaneous effect would cause them to be by time of resolution.

2. More broadly, "choose an X" abilities are requirements. Ketsu or Vader crew can't be added to the queue if no target is in range/arc at the trigger, even if a simultaneous effect would cause them to be by the time of resolution.

Note that this also raises the second question of when the target has to be chosen, or if any target must be legal and you pick one upon resolution.

3. Even more broadly-er, abilities must be fully able to resolve to completion to be able to add them to the queue. This would apply to something like Old Teroch, who selects a target, then checks if he is in that target's front arc. Or something like DBS-32C, which would not be able to be added to the queue if it didn't already have a calculate token to spend.

I don't know which of these is correct.

I also don't believe anyone who says they think they do unless they're on FFG payroll or marshalling an event I'll personally attend.

10 hours ago, Mace Windu said:

I think the best way to look at what a conditional requirement would be this:

If the ability were to trigger and resolve straight away, would you meet all the conditions in the ability? in the case of Old T you need to have the same target at R1 both when the ability triggers and when it resolves.

having said that FFG's genuine attempt to clarify multiple triggered effects does need some clarification work, and they probably need to find a group of playtesters to stress test their rules updates before releasing them to avoid these sorts of questions coming up everytime a new rules update is released.

A general rule could indeed be: "If the ability were to trigger and resolve straight away, would you meet all conditions of the ability? If so, add it to the queue." However, why would you need the same target? At no point in the new rule does it lock you down with the notion of a target, which is also part of what is causing me a headache. Here is an example that's been bugging me:

You have Ketsu and Old Teroch vs Soontir and a tie Academy. Old Teroch is facing the tie Academy, Ketsu Soontir. Scum has initiative.

Queue starts:

- Scum Adds Kestu ability, intended target Soontir

- Scum Adds Old Teroch ability: the tie academy is at range 1.

- Imperial adds Soontir abilty: Ketsu is in the bullseye.

Resolution:

- Ketsu tractor beams Soontir towards Old Teroch.

- Old Teroch does have an ability in the queue. I don't think that at this stage, there is anything preventing him from changing targets to Soontir.

- Assuming that Old Teroch is not in Soontir's bullseye, Soontir's ability fizzles.

Another example:

Player #1 : Palob

Player #2 (has initiative): Manaroo with focus and a Z-95. Both in range 2 and in arc of Palob.

Queue starts:

Player #2: adds Manaroo to transfert focus to Z-95.

Player #1: adds Palob ability to steal Manaroo's focus.

Resolution:

Player #2: transfers focus to Z-95

Player #1: Manaroo is no longer a legal target for stealing, but there's nothing preventing him from stealing from the Z-95 at this moment, correct? The ability still includes the right to choose the target.

FFG sure gave us a head scratcher just to try and clarify Ensnare

9 hours ago, Mace Windu said:

I think the best way to look at what a conditional requirement would be this:

If the ability were to trigger and resolve straight away, would you meet all the conditions in the ability? in the case of Old T you need to have the same target at R1 both when the ability triggers and when it resolves.

having said that FFG's genuine attempt to clarify multiple triggered effects does need some clarification work, and they probably need to find a group of playtesters to stress test their rules updates before releasing them to avoid these sorts of questions coming up everytime a new rules update is released.

I think that's kinda a bad way to look at it. FFG needs to put more work into it, no doubt, but im of the opinion that anything after the requirement for the queue, happens when the ability actually resolves. Otherwise you are just resolving the ability at the time it enters the queue, so what would be the point of the queue?

35 minutes ago, dotswarlock said:

FFG sure gave us a head scratcher just to try and clarify Ensnare

It wasn't even to clarify it, how we thought it worked prior to this FAQ was clear, it was just slightly too powerful and much too unfun for the opponent, particularly when it cam to chained Ensnares. So they stopped them chaining in a really, really difficult way.

5 hours ago, thespaceinvader said:

It wasn't even to clarify it, how we thought it worked prior to this FAQ was clear, it was just slightly too powerful and much too unfun for the opponent, particularly when it cam to chained Ensnares. So they stopped them chaining in a really, really difficult way.

So similarly to how this change effects Anakin they're trying to errata without errata and messing up the whole works in the process?

7 hours ago, thespaceinvader said:

It wasn't even to clarify it, how we thought it worked prior to this FAQ was clear, it was just slightly too powerful and much too unfun for the opponent, particularly when it cam to chained Ensnares. So they stopped them chaining in a really, really difficult way.

I kind of long for the days of "this is how it works because we said so" rulings, like First Edition Autothrusters not working against The Inquisitor's attacks.

On 9/20/2019 at 3:09 PM, Lyianx said:

Otherwise you are just resolving the ability at the time it enters the queue, so what would be the point of the queue?

"The ability queue is used to resolve the timing of multiple abilities that
trigger during the same timing window."

From the RR.

On 9/20/2019 at 10:03 PM, svelok said:

Three "tiers" of possibilities:

1. Strictly "if X..." abilities are requirements. Ensnare or Anakin can't fire unless their "if" clause is met when they're put into the queue, even if a simultaneous effect would cause them to be by time of resolution.

2. More broadly, "choose an X" abilities are requirements. Ketsu or Vader crew can't be added to the queue if no target is in range/arc at the trigger, even if a simultaneous effect would cause them to be by the time of resolution.

Note that this also raises the second question of when the target has to be chosen, or if any target must be legal and you pick one upon resolution.

3. Even more broadly-er, abilities must be fully able to resolve to completion to be able to add them to the queue. This would apply to something like Old Teroch, who selects a target, then checks if he is in that target's front arc. Or something like DBS-32C, which would not be able to be added to the queue if it didn't already have a calculate token to spend.

I don't know which of these is correct.

I also don't believe anyone who says they think they do unless they're on FFG payroll or marshalling an event I'll personally attend.

After reading the examples in the rules reference through again I'm 99% certain it's 1.

Specifically, this part:

Quote

While [Jake Farrell] resolves his ship ability, he performs a red [Boost] action. This triggers
his pilot ability and his ship ability again. He chooses to add his pilot ability
first, then his ship ability.

While resolving his pilot ability again, he chooses a friendly Phoenix Squadron
Pilot (A-wing) at range 1. The other A-wing performs a focus action and its
ship ability triggers. This is added to the front of the ability queue.

Important points to note:

Firstly, Jake's ship ability ("After you perform an action, you may perform a red boost action") is added to the queue even though it cannot resolve. At the time it is added Jake has already performed a boost action and is stressed, and you cannot perform the same action twice in one round nor perform actions while stressed (except via certain upgrades). This completely rules out option 3 - an ability can be queued even when it can't be resolved, and the resolution of the ability is separate from the requirements to trigger it.

Secondly, "While resolving his pilot ability again, he chooses..." implies that choosing is part of the resolution of the ability. Since we have just established that whether you're able to resolve an ability does not impact whether it goes into the queue, this means that abilities with similar phrasing to Jake's pilot ability ("After X, you may choose Y") always goes into the queue after X, because choosing is part of the resolution and not the requirement. This rules out option 2.

This is also supported by the second example:

Quote

Rachel, the Rebel player, is flying “Chopper” (VCX-100) and a Kyle Katarn
(HWK-290). Sam, the Scum player, is flying Old Teroch (Fang Fighter)
equipped with Static Discharge Vanes.

At the start of the Engagement Phase, “Chopper,” Kyle Katarn, and Old Teroch
have abilities that trigger. “Chopper’s” ability is “At the start of the
Engagement Phase, each enemy ship at range 0 gains 2 jam tokens.” Since
Rachel is the first player, she will resolve “Chopper’s” ability first.

Note that range, arc, and whether anyone has any green tokens are not considered or even mentioned until after the abilities have all triggered and are being resolved. This implies that they are not relevant to whether the abilities actually go into the queue.

2 hours ago, Ysenhal said:

Important points to note:

Firstly, Jake's ship ability ("After you perform an action, you may perform a red boost action") is added to the queue even though it cannot resolve. At the time it is added Jake has already performed a boost action and is stressed, and you cannot perform the same action twice in one round nor perform actions while stressed (except via certain upgrades). This completely rules out option 3 - an ability can be queued even when it can't be resolved, and the resolution of the ability is separate from the requirements to trigger it.

Secondly, "While resolving his pilot ability again, he chooses..." implies that choosing is part of the resolution of the ability. Since we have just established that whether you're able to resolve an ability does not impact whether it goes into the queue, this means that abilities with similar phrasing to Jake's pilot ability ("After X, you may choose Y") always goes into the queue after X, because choosing is part of the resolution and not the requirement. This rules out option 2.

Unfortunately I doubt that the rules guys even read through their own, initial examples of the ability queue when they decided to reword how the ability queue works.

On 9/20/2019 at 10:47 PM, emeraldbeacon said:

I kind of long for the days of "this is how it works because we said so" rulings, like First Edition Autothrusters not working against The Inquisitor's attacks.

Yeah.

I mean, obviously the guys designing the cards have some idea of what they want the card to do, or how it needs to work. It is technically after all a tabletop/board game , so they should be able to just say how they want it to work.

The problem is, with a game like this, especially one with a fairly large tournament scene, they can't just declare some interactions work, and others don't. Because the game is being played all over the world, and for the competative side to work, they all need to be playing the same game.

I would say one of the big problems with the queue is the multiple trigger times. And fuzzy definitions. cost vs requirement vs condition.

"Immediately Before", "at the start of", "at the end of", "during", "while" and and and.

So now, instead of the game having 5 nicely defined phases (Plan, System, Activate, Engage, End), its broken into zillion tiny little sub phases. And sure, some sub-phasing makes sense. Breaking up the engagement phase into nice steps to specify exactly when which player can modify dice is a step in the right direction.

I must say their latest change does remind me a bit of MTG, so I'm quite happy to play it that way.

You first "declare" an ability/effect, at which time all targets must be legal. This then goes onto the queue (stack in the case of MTG). Then, when the game tries to "resolve" the ability all targets must still be legal. BUT, as @dotswarlock pointed out, there is nothing that states that the target on declaration HAS to be the same target as during "resolution". It must just be legal. I haven't played magic in years so I can't even remember if you were allowed to change targets there. But hey, we can't ust MTGs wording to prove/disprove anything for X-Wing.

You can not change targets once something is on the stack in MtG. If the target goes the effect on the stack "fizzles"/just doesn't occur.

1 hour ago, Frimmel said:

You can not change targets once something is on the stack in MtG. If the target goes the effect on the stack "fizzles"/just doesn't occur.

Cool. thanks... thought that's how it worked, but wasn't 100% certain any more.

On 9/20/2019 at 2:37 PM, dotswarlock said:

A general rule could indeed be: "If the ability were to trigger and resolve straight away, would you meet all conditions of the ability? If so, add it to the queue." However, why would you need the same target? At no point in the new rule does it lock you down with the notion of a target, which is also part of what is causing me a headache. Here is an example that's been bugging me:

You have Ketsu and Old Teroch vs Soontir and a tie Academy. Old Teroch is facing the tie Academy, Ketsu Soontir. Scum has initiative.

Queue starts:

- Scum Adds Kestu ability, intended target Soontir

- Scum Adds Old Teroch ability: the tie academy is at range 1.

- Imperial adds Soontir abilty: Ketsu is in the bullseye.

Resolution:

- Ketsu tractor beams Soontir towards Old Teroch.

- Old Teroch does have an ability in the queue. I don't think that at this stage, there is anything preventing him from changing targets to Soontir.

- Assuming that Old Teroch is not in Soontir's bullseye, Soontir's ability fizzles.

My point was actually that in X-Wing that is not stated so explicitly, but I think its implied.

I think the entire ability, targets included goes onto the queue, not just a "place holder" for the ability to happen and targets chosen at resolution. You can only resolve against the original chosen target providing it is still legal by the time of resolution. (Similar to MTG)

5 hours ago, Bort said:

I think the entire ability, targets included goes onto the queue, not just a "place holder" for the ability to happen and targets chosen at resolution. You can only resolve against the original chosen target providing it is still legal by the time of resolution. (Similar to MTG)

That would be inconsistent with the way things work in x-wing, as it is the exact opposite of how attacking works. It would also be problematic with things like failed actions and pre-measuring. And how does that work with that things like Locks. where you don't measure until you perform the action and you explicitly don't declare what you are locking until after the measuring?

Besides, the ability queue isn't "fixed" at any point, as new actions can be added to the queue at any time. Linked actions even explicitly say that the player doesn't have to decide to perform the linked action until after it performs the first action.

2 hours ago, Nspace said:

That would be inconsistent with the way things work in x-wing, as it is the exact opposite of how attacking works. It would also be problematic with things like failed actions and pre-measuring. And how does that work with that things like Locks. where you don't measure until you perform the action and you explicitly don't declare what you are locking until after the measuring?

Agree... and not agree. I may have slightly oversimplified it (I was just trying simplify some complexities) and you may be correct for the case of Lock. But the way the Lock ability works doesn't require a target for declaration. The target is selected as part of resolution. So for the case of Lock the ability goes onto the queue target-less.

Failed actions on the other hand, you have to declare the action with the direction at the same time. That is exactly why they have a chance to fail.

RR p5: • When a player declares to barrel roll a ship, that player also declares whether the ship is barrel rolling to the left or right.

RR p7 • When a player declares to boost a ship, that player also declares whether the ship is boosting straight, left, or right.

So they do start out with direction already locked in. And if you then can't do the move if that direction it fails. So actually it works perfectly well with how I tried to explain it.

2 hours ago, Nspace said:

Besides, the ability queue isn't "fixed" at any point, as new actions can be added to the queue at any time. Linked actions even explicitly say that the player doesn't have to decide to perform the linked action until after it performs the first action.

Erm, not 100% certain I know what you mean with "fixed". But I'll answer to what I think you mean.

In X-wing the queue is fixed at specific points, at which new abilities can no longer be added.

You can add abilities that triggers "during" or "while" at any time.

But anything with a "start of x", or "after" or "end of" triggers goes onto the queue at the same time. And you can't add more abilities with the exact same timing trigger later.

For example: Heightened Perception and Torkul Mux

At the start of the Engagement Phase, you may choose 1 ship in your firing arc. If you do, that ship engages at initiative 0 instead of its normal initiative value this round.

At the start of the Engagement Phase, you may spend 1 . If you do, engage at initiative 7 instead of your standard initiative value this phase.

They both go onto the queue at the same time, sequence determined by player order. Once you start resolving "at the start of" abilities you can't add new ones with the same timing. The time has passed.

So if the two abilities are controlled by 2 different players, the end effect depends on who is player one.

This is exactly what just got changed. Ensnare goes onto the queue "at the end of activation" phase. And all ships have to, simultaneously add their ensnares onto the queue, and can only do so if they can legally (can meet all the costs and requirements) do it. Ie. they must already be tractored.

For linked actions, they have a specific time they go onto the queue. "after a ship performs an action..."

RR p 12• After a ship performs an action with an attached linked action, if the player wants to resolve the linked action, it is added to the ability queue.

At that point in time you can choose to add it to the queue or not. Doesn't change anything in terms of what I said that things added to the queue must be added with all requirements met.

11 hours ago, Bort said:

My point was actually that in X-Wing that is not stated so explicitly, but I think its implied.

I think the entire ability, targets included goes onto the queue, not just a "place holder" for the ability to happen and targets chosen at resolution. You can only resolve against the original chosen target providing it is still legal by the time of resolution. (Similar to MTG)

However, this is inconsistent with both examples of using the ability queue given in the rules reference appendix. In both, abilities are added to the queue without specifying a target, and choosing targets is described as part of resolving the ability. Also, in the second, Old Teroch's ability is added to the queue, and then later said to do nothing when resolving because neither of the two enemy ships available are valid targets - which suggests that if either were valid he could choose that one at the time of resolving the ability.

Also, if we're playing MTG rules, I'm going to insist that instead of engaging in initiative order all my ships rotate 90 degrees and then attack simultaneously. 😜

5 hours ago, Ysenhal said:

However, this is inconsistent with both examples of using the ability queue

Both of which were written (and not revised) before they added this:

• If an ability’s requirements are not met, it cannot be added to the ability queue. For example, at the start of the Engagement Phase, if a ship has an ability that requires it to be tractored, but that ship is not tractored,
that ability cannot be added to the queue. The ship cannot add the ability to the queue even if another ability also added to the queue at the start of the Engagement Phase would cause that ship to become tractored upon
its resolution.

to the ability queue rule.

Unfortunately FFG made a knee-jerk rule change to reign in Nantex Tractor-Jitsu, but I honestly doubt they took the time to revise or think about all the other implications.

Which just brings us right back to what this thread is about. What is a requirement?

*Edit. The point I'm trying to make is that with the new wording on ability queue we clearly need to check requirements before adding something to the queue. So is the selected target, and it being legal part of what we need to check? I would say yes, but "requirements" of an ability is so vague that I can't argue the point.

Can we later change this target to another legal one? I don't know. I don't think you should be allowed to, but clearly you feel different.

2 hours ago, Bort said:

Both of which were written (and not revised) before they added this:

• If an ability’s requirements are not met, it cannot be added to the ability queue. For example, at the start of the Engagement Phase, if a ship has an ability that requires it to be tractored, but that ship is not tractored,
that ability cannot be added to the queue. The ship cannot add the ability to the queue even if another ability also added to the queue at the start of the Engagement Phase would cause that ship to become tractored upon
its resolution.

to the ability queue rule.

Unfortunately FFG made a knee-jerk rule change to reign in Nantex Tractor-Jitsu, but I honestly doubt they took the time to revise or think about all the other implications.

Which just brings us right back to what this thread is about. What is a requirement?

*Edit. The point I'm trying to make is that with the new wording on ability queue we clearly need to check requirements before adding something to the queue. So is the selected target, and it being legal part of what we need to check? I would say yes, but "requirements" of an ability is so vague that I can't argue the point.

Can we later change this target to another legal one? I don't know. I don't think you should be allowed to, but clearly you feel different

And what I'm saying is that because they didn't revise or remove those examples, we have to assume they're still correct. I don't think you can just throw out part of the rules on the assumption that FFG are incompetent and forgot to update them. Maybe if the rules outright conflicted and it was impossible to find an interpretation that was consistent with both, or the only consistent interpretation was completely impractical or nonsensical, but I don't think that's the case here. There is an interpretation which is consistent with all the rules and which is still practical: that "requirements" means the timing and explicit conditions for the ability to trigger (e.g. "At the end of the Activation Phase, if you are tractored" for Ensnare).

In any event, I see there's an AMA scheduled for next week and someone has already asked for clarification on this in the relevant thread, so hopefully they'll clear up any confusion then.

3 hours ago, Bort said:

Both of which were written (and not revised) before they added this:

A rule-making document is not a LIFO (Last in - first out) stack. One cannot assume one entry is more valid than the other bases on which one was the latest to be added. You arguing the old entries have to be "outdated" now is as logical as me arguing the new entry is "invalidated" by the fact it doesn't comfort with the long established previous rules.

If two entries in the document are directly contradicting one another, then neither ought to be followed as no sense of priority is given to choose between them.

In our case the two entries can coexist as long as we conclude that abilities granting effect X may only enter the queue at timing Y given the requirements Z are met, where abilities are built like "When Y, if Z, you must / may X". There's a plethora of such abilities with well defined Z, enough to assume this is what the new RR entry references. We should not feel obligated to find a Z bit in every ability in the game. Nothing in the rules update indicates every ability has requirements - rather that any ability that has requirement must meet these requirements to enter the queue.

On 9/24/2019 at 1:44 AM, S4ul0 said:

"The ability queue is used to resolve the timing of multiple abilities that
trigger during the same timing window."

From the RR.

That was rhetorical, but thank you for proving my point. You resolve abilities according to the queue, not according to the trigger.

so, do we consider an ability requirement to be associated with the use of the word "if" in card text - and in that case, how? like the example in the RR:

"• If an ability’s requirements are not met, it cannot be added to the ability queue. For example, at the start of the Engagement Phase, if a ship has an ability that requires it to be tractored, but that ship is not tractored, that ability cannot be added to the queue."




meaning abilities are worded in the following order:
timing (not always present)
requirement(s) (not always present)
effect(s) (these also sometimes have requirements using "if", or more often "if you do", but do we consider them to be ability requirements?)

examples:





to explain in more detail what i'm asking about - do we consider some effects that abilities have to be ability requirements as well, meaning not just when "if" is used, but also "if you do"? or can you still add the abilities to the queue at the timing described and when they are resolved choose the target for the ability no matter if that target was valid when the ability was added to the queue? if you think a target is needed when adding the ability to the queue, can you switch targets when the ability resolves? examples:

please note that not all abilities have strict timings. they use a requirement as a timing instead, such as the nimble bomber ship ability on the tie bomber, "If you would drop a device...".

the word "if" is often used in card text to stipulate extra limits posed by some abilities as well, such as advanced sensors, "If you do, you cannot perform another action during your activation.".

can you decline to resolve an ability added to the queue?

your thoughts and reflections, please.

2 hours ago, meffo said:

so, do we consider an ability requirement to be associated with the use of the word "if" in card text - and in that case, how?

[Cards etc.]

I don't think the word "if" is necessarily associated with an ability requirement. It often is, but not always. I think the overall structure / grammar is more important - are you being told do something or that you may do something (including choosing things)? If so it's part of the resolution.

A good rule of thumb is that if you remove the requirements from the start of the paragraph, you still have a complete sentence in the form of an instruction.

Regarding the cards you mention, I've put what I would consider the requirements in italics :

Shadow Caster: After you perform an attack that hits, if the defender is in your front arc and your mobile arc , the defender gains 1 tractor token.

Advanced SLAM: After you perform a SLAM action, if you fully executed the maneuver, you may perform a white action on your action bar, treating that action as red.

Composure: After you fail an action, if you have no green tokens, you may perform a focus action.

These are all in the "After X, if Y, do Z" format and are fairly straightforward IMO. Note how they form an instruction if you remove the requirements - "The defender gains 1 tractor token." "You may perform a focus action."

Old Teroch: At the start of the engagement phase, you may choose 1 enemy ship at range 1. If you do and you are in its [Front arc], it removes all of its green tokens.

Concordia Faceoff: While you defend, if the attack range is 1 and you are in the attacker's [Front arc], change 1 result to an [Evade] result.

Ketsu Onyo: At the start of the engagement phase, you may choose 1 ship in both your [Front arc] and [Mobile arc] at range 0-1. If you do, that ship gains 1 tractor token.

4-LOM: While you perform an attack, after rolling attack dice , you may name a type of green token. If you do, gain 2 ion tokens and, during this attack the defender cannot spend tokens of the named type.

These are slightly less clear, but I don't consider anything after "you may" to be part of the trigger, because it's telling you to do something (and you explicitly have the option of not doing it). Note they still form an instruction if you remove the requirements: "You may choose 1 enemy ship at range 1. If you do and you are in its [Front arc], it removes all of its green tokens."

Another one to consider is Feedback Array:

Feedback array: Before you engage , you may gain 1 ion token and 1 disarm token. If you do, each ship at range 0 suffers 1 [Hit] damage.

This follows the same structure as the ones above, but in this case I think it's clearer that the text following "you may" should be considered part of the resolution, since it has an immediate effect (adding the tokens).

Similarly Static Discharge Vanes, which has double the "if":

Static Discharge Vanes: Before you would gain 1 ion or jam token, if you are not stressed , you may choose another ship at range 0-1 and gain 1 stress token. If you do, the chosen ship gains that ion or jam token instead.

This actually has the "you may choose another ship" wording, but you get a stress token as a result of the choosing.

10 minutes ago, Ysenhal said:

I don't think the word "if" is necessarily associated with an ability requirement. It often is, but not always. I think the overall structure / grammar is more important - are you being told do something or that you may do something (including choosing things)? If so it's part of the resolution.

A good rule of thumb is that if you remove the requirements from the start of the paragraph, you still have a complete sentence in the form of an instruction.

Regarding the cards you mention, I've put what I would consider the requirements in italics :

[text]

so you consider the timing to be part of the ability's requirement as well? that makes sense practically. i still think it would be more helpful to define ability's requirements separate from timings, though, since we already know you cannot add abilities to the ability queue unless they have a timing or have headings such as Attack: or Action:, which can also be viewed as a requirement, or in a non game term, a trigger.

do you think you can decline to resolve an ability you've put in the queue even if there is no "may" in the ability? i'm guessing no.

do you have examples of abilities with requirements (and not just timings or headings) that don't use "if"?

i mean, obviously there are abilities that cannot be resolved unless certain parameters are fulfilled in the game state, but unless they use "if" they all have timings or headings as far as i know.