15 hours ago, meffo said:

in believe the intent was always for abilities with a requirement ("if you are tractored", "if you fully execute a maneuver", "if you have no green tokens", basically a requirement of a certain game state to be fulfilled ) to not be able to enter the queue and the ability queue to be constructed at a single point in time.

there is no such thing as a trigger, jake's ability simply has a timing and an effect.

Teroch has a timing and a game state and an effect. "

"At the start of the engagement phase," would be the timing.

"you may choose 1 enemy ship at range 1. If you do and you are in its {front arc}," would be the game state.

"it removes all of its green tokens" would be the effect.

Back to Nantex/Ensnare. It doesn't put the chance to do tractored things when you eventually get a tractor token into the queue. Ensnare also timing, game state, effect:

"At the end of the activation phase" = timing.

"if you are tractored, you may choose one ship in your turret arc at range 0-1." = game state

"Transfer one tractor token to it." = effect.

So if we go back to Jake:

"After you perform a boost or barrel roll action" = timing

"you may choose a friendly ship at range 0-1." = game state

"That ship may perform a focus action." = effect.

Jake's ship ability even works with that:

"After you perform an action," = timing

"you" = game state

"may perform a red boost action." = effect

Teroch should never have worked with Ketsu. And he shouldn't work now. It isn't the timing queue. It is the ability queue. Abilities are put into the queue. It is not opportunities to use abilities under more favorable circumstances that is put into the queue.

I think I've found my answer to what a "requirement" is. A met timing and met game state and a met place/direction/target/ or "object" perhaps for the effect.

Has someone made this argument already? Maybe another thread? I feel like this isn't all mine.

56 minutes ago, Frimmel said:

I think I've found my answer to what a "requirement" is. A met timing and met game state and a met place/direction/target/ or "object" perhaps for the effect.

Has someone made this argument already? Maybe another thread? I feel like this isn't all mine.

Not the same words, but comes down to the same when I said that the ability along with the selected target goes onto the queue. I played devil's advocate by comparing it to the MTG stack and got hit down hard.

Truth be told, I only made the argument because I was trying to understand the workings of the queue, not because I'm convinced one way or the other.

56 minutes ago, Frimmel said:

It isn't the timing queue.

Erm, that is literally what it is.

RR p3. "• If multiple abilities resolve at the same time , the players use the ability queue to determine the order in which the abilities resolve."

*EDIT. Just to clarify. I'm not trying to pick a fight. I'm just no closer to understanding "a requirement" now than when this thread started.

3 minutes ago, Bort said:

Not the same words, but comes down to the same when I said that the ability along with the selected target goes onto the queue. I played devil's advocate by comparing it to the MTG stack and got hit down hard.

Truth be told, I only made the argument because I was trying to understand the workings of the queue, not because I'm convinced one way or the other.

Well, that would explain it. I tend to look back to MtG since at this point it is more or less all through lots of games.

5 minutes ago, Bort said:

Erm, that is literally what it is.

RR p3. "• If multiple abilities resolve at the same time , the players use the ability queue to determine the order in which the abilities resolve."

Sure but you don't put opportunities in it. You put abilities in it. In the Jake example the whole thing <ship ability instance 1> went in.

Do we have time to talk about time? You have Moment A. Events X and Y happen at moment A. If Event X can only happen after Event Y, then Event X isn't happening at moment A. Event X is happening at Moment A+Moment After Event Y.

That's the new language. Event X can not go in the queue dependent on Moment A+Moment After Event Y. It has to go in dependent on Moment A.

The Queue just tells you whether to do Event X or Event Y first to keep order in the game. And we determined initiative to tell us who decides if Event X or Event Y will be ordered first.

2 hours ago, Lyianx said:

Perhaps, but its a pretty solid one given the example of Jake in the appendix, unless they really screwed that up, which isn't out of the realm of possibility. But given how convoluted the ability queue can be, it feels like they knew how it worked was kinda complicated, which is why they have 2 fleshed out examples of how it works. Its probably not something they can easily (or rather, efficiently) list a bunch of bullet points or straight up rules in a paragraph in under the "Ability" subtext on pg 3.

i agree it's pretty solid in my eyes, but since there are obviously a bunch of people with a different opinion, it is definitely not solid enough.

i also don't see why it would be that hard to define an ability's requirement under "Ability" (that's mostly page 2, no?). especially if they throw in a couple of examples.

1 hour ago, Frimmel said:

Teroch has a timing and a game state and an effect. "

"At the start of the engagement phase," would be the timing.

"you may choose 1 enemy ship at range 1. If you do and you are in its {front arc}," would be the game state.

"it removes all of its green tokens" would be the effect.

Back to Nantex/Ensnare. It doesn't put the chance to do tractored things when you eventually get a tractor token into the queue. Ensnare also timing, game state, effect:

"At the end of the activation phase" = timing.

"if you are tractored, you may choose one ship in your turret arc at range 0-1." = game state

"Transfer one tractor token to it." = effect.

So if we go back to Jake:

"After you perform a boost or barrel roll action" = timing

"you may choose a friendly ship at range 0-1." = game state

"That ship may perform a focus action." = effect.

Jake's ship ability even works with that:

"After you perform an action," = timing

"you" = game state

"may perform a red boost action." = effect

Teroch should never have worked with Ketsu. And he shouldn't work now. It isn't the timing queue. It is the ability queue. Abilities are put into the queue. It is not opportunities to use abilities under more favorable circumstances that is put into the queue.

I think I've found my answer to what a "requirement" is. A met timing and met game state and a met place/direction/target/ or "object" perhaps for the effect.

Has someone made this argument already? Maybe another thread? I feel like this isn't all mine.

i don't agree at all. game state is the state of the game at any given time. clearly, ability's requirements will often reference the game state, or rather, part of the game state, as in "if you are tractored". game state is not part of abilities and to my knowledge it isn't even a game term, just a wording i used to describe my reasoning. "you may choose..." is clearly an effect of an ability - and not a game state.

just to be clear on how i intrepret this:

"At the end of the activation phase" = timing.

"if you are tractored," = ability's requirement (referencing part of the game state)

"you may choose one ship in your turret arc at range 0-1. T ransfer one tractor token to it." = effect.

further thougts and comments are most welcome.

8 hours ago, meffo said:

just to be clear on how i intrepret this:

"At the end of the activation phase" = timing.

"if you are tractored," = ability's requirement (referencing part of the game state)

"you may choose one ship in your turret arc at range 0-1. T ransfer one tractor token to it." = effect.

further thougts and comments are most welcome.

just from a grammatical standpoint if the last part of the text was the whole "Effect" why would the put the full stop in the middle of it?

Surely if the way you read it FFG would have worded the effect:

"you may choose one ship in your turret arc at range 0-1 and t ransfer one tractor token to it."

I would say that the range and turret restriction are part of the ability requirement. this is also why I feel the range and arc restriction on Old T are also an ability requirement but frankly until FFG clarify what constitutes a trigger requirement there will be ongoing disagreements regarding many abilities.

If for example Old T was worded:

"At the beginning of engagement if there is an enemy ships at range 1 and you are in it's arc, you may remove all of that ships green tokens"

It would be functionally identical to its current iteration, but would definitely not work with Ketsu combo. because of this I feel that FFG will rule that range and arc restrictions on abilities will need to be met to put the ability in the queue, but that's just my opinion of course.

2 hours ago, Mace Windu said:

If for example Old T was worded:

"At the beginning of engagement if there is an enemy ships at range 1 and you are in it's arc, you may remove all of that ships green tokens"

It would be functionally identical to its current iteration, but would definitely not work with Ketsu combo. because of this I feel that FFG will rule that range and arc restrictions on abilities will need to be met to put the ability in the queue, but that's just my opinion of course.

It's likely because they want target choice and the effect of it to be separate. Based on their Jake example, they don't want a Target to be chosen until the effect is being resolved. However it doesnt make grammatical sense to say "At the start of engagement. You may choose an enemy ship at range 0-1....".

To me, I think abilities have 4 different sections:

1: Trigger: this is when the ability is able to start resolving, in the cases when there's multiple abilities that have the same trigger, the ability queue is used to determine the order.

2: Requirement: This is wording such if you tractored, if you are not stressed, etc. These are conditions that need to be met to resolve the ability and need to be met at the time when an ability enters the queue (but may no longer be met when its that's abilities turn to resolve, causing it to have no effect) .

3:Target choice: This is when a Target for the ability is chosen. This is part of the resolution of the ability so it only matters once the ability it is attached to reaches the front of the queue. This is included language like you may choose an enemy ship etc. This is not part of a requirement as shown by the Jake Ferrell example, since they do not mention anything about a Target until his pilot ability is being resolved. Not every ability has a Target choice.

4: Effect: This is any thing after the target is chosen. It is what is the ability itself does. It includes paying costs, (gain 1 tractor to, gain an ion token) and resolving the effect, (If you do, that ship removes it's green tokens, perform a rotate action etc).

Usually the trigger, requirement, and target choice are all part of the first sentence, and the effect is in a second sentence. But there are cards the are all one sentence. Usually it feels as it's arbitrary and just based on what sounds good.

Some examples are the pinpoint tractor array vs static discharge. One has a single sentence using to as part of the cost, the other has you pay a cost, then a new sentence saying, If you do.

1 hour ago, SirToastsalot said:

It's likely because they want target choice and the effect of it to be separate. Based on their Jake example, they don't want a Target to be chosen until the effect is being resolved. However it doesnt make grammatical sense to say "At the start of engagement. You may choose an enemy ship at range 0-1....".

Honestly I don’t necessarily think its deliberate, and frankly I’d be disappointed if in fact FFG rule that legal target selection is not required for the ability to go in the Queue. This sort of open ended target selection for an ability tends to lead to game breaking combos more often than not, the more abilities worded like this that enter the game the more likely someone is to pull together a degenerate combo that was clearly unintended.

There is an FFG AMA on in the next day or so, I can only hope that they clarify with absolute certainty what is and what isn’t a requirement for an ability to be put in the queue. As it is Worlds is going to have a lot of judge calls on what players think should and shouldn’t enter the queue if they don’t clarify these issues.

9 hours ago, Mace Windu said:

just from a grammatical standpoint if the last part of the text was the whole "Effect" why would the put the full stop in the middle of it?

An interesting question! Consider the case of Static Discharge Vanes, which received an errata:

Original text: " If you would gain an ion or jam token, you may choose a ship at range 0–1. If you do, gain 1 stress token and transfer 1 ion or jam token to that ship."

Amended text: "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."

The amended text adds a requirement that you are not stressed, but also makes gaining a stress token part of the first sentence instead of the second. Perhaps it's just for readability or consistency? There are certainly ways you could phrase abilities like this to make it less ambiguous where the line between requirement and effect is, but it would often make them sound awkward or hard to read.

I'd actually be curious how you and @Frimmel interpret Static Discharge Vanes. With the amended text, it seems as if gaining a stress is part of choosing a target. Do you agree? If you have to choose before an ability goes on the queue, does that mean you become stressed when SDV is added to the queue, before any abilities actually resolve?

(And yes, fingers crossed they clarify it in the AMA).

3 hours ago, Ysenhal said:

I'd actually be curious how you and @Frimmel interpret Static Discharge Vanes. With the amended text, it seems as if gaining a stress is part of choosing a target. Do you agree? If you have to choose before an ability goes on the queue, does that mean you become stressed when SDV is added to the queue, before any abilities actually resolve?

Well here is the wording I will answer that to.

So by my previous reasoning,

"Before you would gain 1 ion or jam token" = timing

"if you are not stressed, you may choose another ship at range 0-1 and gain 1 stress token. If you do," = game state

"the chosen ship gains that ion or jam token instead." = effect.

I am of the opinion that when you gain a stress for something or use a force for something or generally pay a cost for something the something happens before you get any possible positive or negative effects of having paid the cost. The ship with SDV does not get the stress until you get to SDV's spot in the queue where the effect happens or fails and the SDV ship gets the stress. After the consequences of the effect are handled then the consequences of gaining a stress token are handled.

I think it is pedantic and petty at best that folks are trying to say ships don't get the things they paid for because of what they paid for it.

22 hours ago, meffo said:

i agree it's pretty solid in my eyes, but since there are obviously a bunch of people with a different opinion, it is definitely not solid enough.

i also don't see why it would be that hard to define an ability's requirement under "Ability" (that's mostly page 2, no?). especially if they throw in a couple of examples.

i don't agree at all. game state is the state of the game at any given time. clearly, ability's requirements will often reference the game state, or rather, part of the game state, as in "if you are tractored". game state is not part of abilities and to my knowledge it isn't even a game term, just a wording i used to describe my reasoning. "you may choose..." is clearly an effect of an ability - and not a game state.

just to be clear on how i intrepret this:

"At the end of the activation phase" = timing.

"if you are tractored," = ability's requirement (referencing part of the game state)

"you may choose one ship in your turret arc at range 0-1. T ransfer one tractor token to it." = effect.

further thougts and comments are most welcome.

Being or not being tractored or stressed or calculating or evading is a game state. A ship at range one. A ship in an arc. An enemy ship just did a maneuver. All game states. "The state of the game at any given time."

A particular game state can be a requirement. Being a requirement doesn't make it cease being a game state. The analogy I'd draw is to squares and rectangles. Game states being rectangles. Requirements being squares. All squares are rectangles. Not all rectangles are squares.

22 hours ago, Frimmel said:

Sure but you don't put opportunities in it. You put abilities in it. In the Jake example the whole thing <ship ability instance 1> went in.

Do we have time to talk about time? You have Moment A. Events X and Y happen at moment A. If Event X can only happen after Event Y, then Event X isn't happening at moment A. Event X is happening at Moment A+Moment After Event Y.

That's the new language. Event X can not go in the queue dependent on Moment A+Moment After Event Y. It has to go in dependent on Moment A.

The Queue just tells you whether to do Event X or Event Y first to keep order in the game. And we determined initiative to tell us who decides if Event X or Event Y will be ordered first.

I actually had to read through your sentence a couple of times to understand what the heck you meant. But now I do.

And yeah, I have to admit this is actually how I originally understood the whole queue thing to work. Ie... you get to a specific time stamp in the game, you check the timing of all abilities at exactly that time. If all requirements are met, you can do the ability, adding it to the queue.

I have subsequently also started to understand the problems with the interpretation: No clear definition of what constitutes a requirement. So adding things you can't do is legal (As shown in the RR example adding Jake's ship ability onto the queue multiple times) and maybe due to sequence of resolution you may be able to do them later.

Without clear definition of requirement you add all abilities with the specified timing onto the queue, even though some of them cannot take place due to some other game restriction. Current queue wording, ability requirements is the only thing preventing it from going onto the queue.

Short of rewording every card in the game I don't see how FFG can resolve this.

Instead of using natural language they could have used formatted language with clear separators.... so, maybe V3.0.

[Timing / Trigger] [Requirements / Restrictions] [Targets] [Effects]

Thing is, to the credit of FFG and the great game X-Wing. They are giving us a game where each pilot and piece of equipment is unique. Not always absolutely unique, but more or less. So they can't just piggy-back on using the same keywords on multiple cards/instances. This does make it extremely hard to break down the each card as I described above. Especially where we have a lot of things that initially sound/look the same, but upon finer (and pedantic) checking found to be entirely different.

17 minutes ago, Bort said:

No clear definition of what constitutes a requirement.

Logically, its this.

This timing happens. Does this condition exist? Then you can add this ability to the queue. Looking for a condition is the requirement. Is that specifically stated? No, because, as quite often, FFG trusted us to work that out for ourselves and "just know" or when they wrote it they had the mindset of "well yeah, of course this is what it means. how can anyone misinterpret this?". Not sure how many eyes they have looking over it, but apparently, they need more.

So probably a better word than "requirement" would be "game state" or "condition".

14 hours ago, Mace Windu said:

just from a grammatical standpoint if the last part of the text was the whole "Effect" why would the put the full stop in the middle of it?

Surely if the way you read it FFG would have worded the effect:

"you may choose one ship in your turret arc at range 0-1 and t ransfer one tractor token to it."

I would say that the range and turret restriction are part of the ability requirement. this is also why I feel the range and arc restriction on Old T are also an ability requirement but frankly until FFG clarify what constitutes a trigger requirement there will be ongoing disagreements regarding many abilities.

If for example Old T was worded:

"At the beginning of engagement if there is an enemy ships at range 1 and you are in it's arc, you may remove all of that ships green tokens"

It would be functionally identical to its current iteration, but would definitely not work with Ketsu combo. because of this I feel that FFG will rule that range and arc restrictions on abilities will need to be met to put the ability in the queue, but that's just my opinion of course.

good question. heck if i know. maybe because you're a game designer and not a writer?

nah, but on a more serious note, it wouldn't have been as clear that way. "you may pick apples and pears." indicates you are allowed to pick apples and pears, or just apples, or just pears, arguably. "you make pick apples and throw them at your friends" could also be interpreted as you may pick apples and you may also throw them on your friends (or eat them or do what ever you like with them). maybe not so much in game terms, but in english, it would have been a valid interpretation of the instruction. but that's besides the point, since it's so irrelevant for x-wing. it's shorter, though. leaves more space on the card, if that's a thing they're going for. i don't know.

i'm sorry, byt why it's worded in one way and not in another doesn't seem like a very relevant topic to dwell upon. we have the wording and we need to interpret it in accordance with the rules.

5 hours ago, Ysenhal said:

An interesting question! Consider the case of Static Discharge Vanes, which received an errata:

Original text: " If you would gain an ion or jam token, you may choose a ship at range 0–1. If you do, gain 1 stress token and transfer 1 ion or jam token to that ship."

Amended text: "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."

The amended text adds a requirement that you are not stressed, but also makes gaining a stress token part of the first sentence instead of the second. Perhaps it's just for readability or consistency? There are certainly ways you could phrase abilities like this to make it less ambiguous where the line between requirement and effect is, but it would often make them sound awkward or hard to read.

I'd actually be curious how you and @Frimmel interpret Static Discharge Vanes. With the amended text, it seems as if gaining a stress is part of choosing a target. Do you agree? If you have to choose before an ability goes on the queue, does that mean you become stressed when SDV is added to the queue, before any abilities actually resolve?

(And yes, fingers crossed they clarify it in the AMA).

this errata changed a lot for static discharge vanes. it became a replacement effect in all it's glory. it disallowed a lot of potential ridiculous combos and freed up design space for future upgrades, especially abilities that has a timing or requirement of gaining a stress or ion or jam token. to me, it's pretty clear that the the timing is "before you would gain 1 ion or jam token," and the ability's requirement is "if you are not stressed," and that the effect is the rest of the text.

we could complicate things much further by splitting up the ability further in more parts, but that seems like a big time waste.

19 minutes ago, Frimmel said:

Being or not being tractored or stressed or calculating or evading is a game state. A ship at range one. A ship in an arc. An enemy ship just did a maneuver. All game states. "The state of the game at any given time."

A particular game state can be a requirement. Being a requirement doesn't make it cease being a game state. The analogy I'd draw is to squares and rectangles. Game states being rectangles. Requirements being squares. All squares are rectangles. Not all rectangles are squares.

no, it's simply a part of a game state, it's an ability's requirement that references a specific part of the game state. "game state" is not a term used in the rules reference what so ever, it's used a bit in the tournament regulations, though. the state of the game at any given time means just that, the state of the game. the whole game, not just part of it.

this thread is dedicated to discussing what an ability's requirement is, in accordance with the OP and the thread title. in the interest of keeping everyone on the same page and making sure we understand each other as well as possible, your addition of "game state" as part of abilities serves no direct purpose, but could be very confusing for many.

as far as i understand you, your use of the term has the same meaning as an ability's requirement, or at least an ability's requirement for a specific element in the game state. is that correct?

1 hour ago, Frimmel said:

Well here is the wording I will answer that to.

So by my previous reasoning,

"Before you would gain 1 ion or jam token" = timing

"if you are not stressed, you may choose another ship at range 0-1 and gain 1 stress token. If you do," = game state

"the chosen ship gains that ion or jam token instead." = effect.

I am of the opinion that when you gain a stress for something or use a force for something or generally pay a cost for something the something happens before you get any possible positive or negative effects of having paid the cost. The ship with SDV does not get the stress until you get to SDV's spot in the queue where the effect happens or fails and the SDV ship gets the stress. After the consequences of the effect are handled then the consequences of gaining a stress token are handled.

I think it is pedantic and petty at best that folks are trying to say ships don't get the things they paid for because of what they paid for it.

this is very interesting. you interpret "if you are not stressed, you may choose another ship at range 0-1 and gain 1 stress token. If you do," to be the abilities requirement? how is it possible to fulfill an ability's requirement without fulfilling part of the requirement (gaining a stress)?

yes, i apologize, but i don't mind being pedantic or petty. i'm not just of the opinion that "if you are not stressed, you may choose another ship at range 0-1 and gain 1 stress token. If you do," is all an ability's requirement.

27 minutes ago, Bort said:

I actually had to read through your sentence a couple of times to understand what the heck you meant. But now I do.

And yeah, I have to admit this is actually how I originally understood the whole queue thing to work. Ie... you get to a specific time stamp in the game, you check the timing of all abilities at exactly that time. If all requirements are met, you can do the ability, adding it to the queue.

I have subsequently also started to understand the problems with the interpretation: No clear definition of what constitutes a requirement. So adding things you can't do is legal (As shown in the RR example adding Jake's ship ability onto the queue multiple times) and maybe due to sequence of resolution you may be able to do them later.

Without clear definition of requirement you add all abilities with the specified timing onto the queue, even though some of them cannot take place due to some other game restriction. Current queue wording, ability requirements is the only thing preventing it from going onto the queue.

Short of rewording every card in the game I don't see how FFG can resolve this.

Instead of using natural language they could have used formatted language with clear separators.... so, maybe V3.0.

[Timing / Trigger] [Requirements / Restrictions] [Targets] [Effects]

Thing is, to the credit of FFG and the great game X-Wing. They are giving us a game where each pilot and piece of equipment is unique. Not always absolutely unique, but more or less. So they can't just piggy-back on using the same keywords on multiple cards/instances. This does make it extremely hard to break down the each card as I described above. Especially where we have a lot of things that initially sound/look the same, but upon finer (and pedantic) checking found to be entirely different.

i like that and i pretty much agree with all of it, except the last part. they simply need some examples in the description of abilities with "if" and "if you do", as well as a loose definition of what constitutes an ability's requirement. granted, while it wouldn't be super clean (at least not as clean as i would have preferred, considering i'm obviously pedantic), it would at least work well. maybe some cards would need further clarification in the FAQ, but as far as i'm concerned, that's fine as long as we're all on the same page and have a clear understanding of how the game works.

1 hour ago, meffo said:

i like that and i pretty much agree with all of it, except the last part. they simply need some examples in the description of abilities with "if" and "if you do", as well as a loose definition of what constitutes an ability's requirement.

The biggest problem with "just having some examples" is exactly because of the uniqueness of each card/ability. Each one works just a little different, to make it unique, which unfortunately also makes it almost but not exactly like any given example.

I totally agree in principle that more examples and FAQ clarifications will get us a lot closer to understanding what their intended mechanics are, but since we are all so pedantic anything that differs even the smallest amount will be thrown out as "not being the same" and hence "not working the same".

Slight Necro, but this topic seems to keep coming up in conversation between myself and other players as well as on a recent podcast.

For context, compare Anakin in the Aethersprite vs. Old Teroch.

Anakin it is universally agreed that now for his ability to be put in the queue there must be an enemy ship at R1 in arc or in his bullseye.

Old T on the other hand seems to be more and more players stating that his ability is not conditional and can go in the queue without there being a ship at R1 and him in their arc.

So we have 2 abilities that are virtually identical with regards to targeting restrictions yet somehow those targeting restrictions are a requirement for 1 ship to put the ability in the queue but not the other.

Can anyone give me a reasonable answer as to why this is, other than "they are worded differently". Yes they are worded differently but I would argue the restrictions of the abilities are virtually indistinguishable.

Is it a case of poor templating that is to blame, or in fact is this actually a deliberate difference in wording from FFG to explicitly allow for this situation to potentially create crazy combos with future cards?

You've pretty much just stated why there's 2 sides to it. It could be looked at both ways. Functionally they are similar, but the wording is different.

It's ambiguous so we really just need the developers to answer what they want. Most of this stuff has died down since the devs said they plan on doing a forum post soon here before worlds.

it's because of wording, yes. anakin has a clear timing and requirement, "after..." and "if...". he's worded in a very similar way to the nantex ability used as an example in the new RR.

old t has a timing and an ability "at the start of...", "you may choose...", "if you do...". no clear ability requirement worded the same way as the nantex ship ability.

5 hours ago, Mace Windu said:

Can anyone give me a reasonable answer as to why this is, other than "they are worded differently". Yes they are worded differently but I would argue the restrictions of the abilities are virtually indistinguishable.

This is exactly my previous point. Examples are good, but we need more general clarifications.

Because as you say, they are worded differently. Sorry if you don't like that answer, but that is the key point. Different wording, different application.

1 hour ago, meffo said:

it's because of wording, yes. anakin has a clear timing and requirement, "after..." and "if...". he's worded in a very similar way to the nantex ability used as an example in the new RR.

old t has a timing and an ability "at the start of...", "you may choose...", "if you do...". no clear ability requirement worded the same way as the nantex ship ability.

Sums it up nicely.

16 hours ago, Mace Windu said:

So we have 2 abilities that are virtually identical with regards to targeting restrictions yet somehow those targeting restrictions are a requirement for 1 ship to put the ability in the queue but not the other.

Can anyone give me a reasonable answer as to why this is, other than "they are worded differently". Yes they are worded differently but I would argue the restrictions of the abilities are virtually indistinguishable.

If Teroch can't just go in the queue without a target then the Ketsu/Teroch combo doesn't work. I think that is the prime motivation for the argument.

I think also it could then make for an argument to be able to put Anakin in without appropriate target. Anakin is kind of unarguable but if Old Teroch can go then you have an argument for Anakin to go as well.

But I'm cynical about the motivations behind rules arguments.

3 hours ago, Frimmel said:

I think also it could then make for an argument to be able to put Anakin in without appropriate target. Anakin is kind of unarguable but if Old Teroch can go then you have an argument for Anakin to go as well.

how and why?

Ideally abilities would all have the same template, something like: at this time ( trigger), if these conditions are met(requirement), then do this thing(effect). But consistency is hard, so we get what we get.

If you look at the ability of Ensnare there's two sentences. The first has a clear timing, requirement, and an effect with an additional arc/range requirement. The second sentence states another effect based on the outcome of the first sentence, but is itself a very simple directive.

Anakin is even simpler since there's only one sentence which, like Ensnare, has a clear timing, requirement, and the effect is even clearer since it only adds a cost. So it's easy to apply the ruling of Ensnare to Anakin, especially given that they even have the same list structure.

Then there's Old Teroch as the poster example of a frustratingly different sentence template. In the first sentence there is only a timing and an effect which is then complicated attaching a range requirement to the effect. The second sentence, like Ensnare, is dependant on the outcome of the first, but this time it adds another requirement.

There are two ways I can see this in regards to the new rule about adding abilities, "If an ability’s requirements are not met, it cannot be added to the ability queue."

1) For purposes of the new rule of entering the Queue, does the whole thing count as a single "ability" for which all requirements must be met simultaneously? The strictest RAW reading of the new rule says, "yes, all requirements must be met. Period."

2) Does the first sentence which is triggered by a game effect count as the "ability" being entered to the Queue and contain all the relevant requirements? In this case the second sentence being triggered by the first's success makes it a separate ability with a separate trigger and is only added to the Queue after the successful resolution of the first sentence.

Honestly, I could go either way, but I think FFG should take weight of precedent into greater account to make it clear that the old combo is not allowed when they drop new rules that invalidate old combos. At the very least they should include the old combo not working as one of the new examples, preferably in the appendix.

Speaking of the appendix, if the new rule invalidated the existing examples (or added complexity to the scenario) those examples really need to be updated!

19 hours ago, Bort said:

This is exactly my previous point. Examples are good, but we need more general clarifications.

Because as you say, they are worded differently. Sorry if you don't like that answer, but that is the key point. Different wording, different application.

So you're ok with practically identical abilities being treated differently just because they the rules writers didn’t use the same text templating?

Both abilities remove tokens.

Both abilities require both ships to be at Range 1 of each other.

Both abilities require 1 of the ships to be in the arc of the other ship.

Both abilities trigger at the same time.

Targeting restrictions of abilities either are or they are not restrictions to putting an ability in the Queue, they have to be one or the other and can't be both. If not then EVERY card printed in the future that has these sort of targeting restrictions will forever be debated until EVERY card has an official FAQ entry clarifying if the restrictions are or are not required to put the ability into the Queue.

2 hours ago, Mace Windu said:

So you're ok with practically identical abilities being treated differently just because they the rules writers didn’t use the same text templating?

Both abilities remove tokens.

Both abilities require both ships to be at Range 1 of each other.

Both abilities require 1 of the ships to be in the arc of the other ship.

Both abilities trigger at the same time.

Targeting restrictions of abilities either are or they are not restrictions to putting an ability in the Queue, they have to be one or the other and can't be both. If not then EVERY card printed in the future that has these sort of targeting restrictions will forever be debated until EVERY card has an official FAQ entry clarifying if the restrictions are or are not required to put the ability into the Queue.

Having a ship in range 1, and choosing a ship in range 1 are not the same thing. Also they both have different triggers.

Anakin isn't targeting a ship when he resolves his ability. He checks to see if one is there, but he is targeting himself. Old Terroch is choosing an enemy ship at range 1 and doing something to that ship.

As you said, they need to clarify what an requirement is, but saying that old terroch and anakin are practically the same is a stretch.

Usually when there are 2 abilities that are similar, but use different wording, its usually intentional because they want them to be different. I personally don't believe that having a valid target is necessary to put an ability into the queue. I think that the Trigger, if condition wording what makes a requirement. Trigger choose a ship wordings are not a requirement. I've already argued as to why. I believe the rule example of Jake is enough to justify that you don't need a valid target when you place an ability into the queue.

An basic entry into the RRG that says what a requirement is enough to clear up confusion I think. Either saying somethiing like "Some abilities have a requirement attached. These are worded as an if statement that follows a trigger. An example would be Anakin Skywalker. Aftter you execute a maneuver, if there is an enemy ship at range 0-1 in your front arc, or in your bullseye arc ."

And a entry that says: "Choosing a target for an ability is not considered a trigger. The only time an ability needs to check for a target is when the ability is resolving."

That would pretty much clear the way and not require a FAQ for every single card.

3 hours ago, Mace Windu said:

So you're ok with practically identical abilities being treated differently just because they the rules writers didn’t use the same text templating?

Oh absolutely. But I'm pedantic about consistency.

(Even little things like the sequence of the actions on the huge ships absolutely annoys me. C-ROC, Raider and Tentive IV all have the same actions. But C-ROC and Raider has them in the sequence Focus, Reinforce, Lock , Coordinate, Jam. But Tantive has them as Focus, Lock, Reinforce , Coordinate, Jam. That is just sloppy. )

This game is full of issues with RAW vs RAI. I'm a very casual player (don't do tournaments), so in reality I'm happy to roll a dice on rules disputes while playing instead of arguing for hours. But when not playing and theorycrafting and thinking about the game... don't get me started.

But bigger picture, for an international tournament level game they really should be consistent with their wording.

6 hours ago, nitrobenz said:

Speaking of the appendix, if the new rule invalidated the existing examples (or added complexity to the scenario) those examples really need to be updated!

This.... so much this.