Hi there. I had a question on the ability que and how it resolves ... I think.

I’m playing with Unkar Plutt who has, at the start of the engagement phase, another (enemy) ship at range 0 of him. Unkar Plutt assigns the enemy small base ship a tractor token and ‘tractors’ that ship into range 1 of Ketsu Onyo. Are we still at the start of the engagement phase?

The enemy ship is now ‘tractored’ by Unkar Plutt at range 0-1 of Kestu Onyo - she has 0-0-0 as crew. Can Kestu Onyo activate 0-0-0, at the start of the engagement phase, in order to gain a calculate token or instead give the enemy a stress token?

And what if the enemy ship is in range 0-1 of Ketsu Onyo, who has 0-0-0 as crew. Both have a 'at the start of the engagement phase' ability. What if I use Ketsu's ability first and 'tractor' an enemy ship beyond range 0 or Ketsu can 0-0-0's ability still be used? I would reverse the order of both abilities in practice but therefore the 'what if'.

Thx.

First scenario:

Engagement starts: all start of engagement abilities on the stack. 0-0-0 has no target, and does not trigger.

Second scenario:

You need to reverse the order, but then it does work. It's possible to disrupt queued abilities by moving targets out of range, it's why snap shot functionality depends on who is first player. Snap shot is added on the stack every time a ship moves. If the person moving is first player they can maneuver into range 2, and then boost out of range 2 before the attack from snap shot triggers, and avoid it, on the other hand if they are not first player, they can maneuver outside of range 2, boost into range 2, and get shot.

In the first scenario, both Unkar Plutt and 0-0-0 will be added to the Queue since 0-0-0 has no explicit requirements, no cost requirements, and no implicit requirements for resolving an attack. He requires you to select a target, but you don't select a target for an ability until you resolve that ability so the available targets when adding him to the queue is irrelevant.

If a player has more than one ability, that has the same trigger, they choose the order in which the abilities trigger. In your situation...

1. Unkar Plutt and 0-0-0 activate at the Start of the Engagement Phase.
2. Unkar Plutt is set up before 0-0-0 in the Ability Queue.
3. Unkar Plutt triggers, assigning a Tractor Token to a small base. All effects of assigning the Tractor Token are resolved now.
4. 0-0-0 triggers and checks for potential targets. Since there is a ship at Range 0-1, all effects of 0-0-0 are resolved normally.

If you decide to activate 0-0-0 before Unkar Plutt, 0-0-0 has no ship it can affect, thus his effect will be failed.

there is not any proper consensus on this, even though i think it's clear.

the whole ability queue must be built at the same time, in this scenario at the start of the engagement pase. my interpretation is that the only one of these three abilities that has an ability's requirement is unkar plutt's. his ability is also mandatory.

0-0-0 and ketsu both have abilities that state "you may choose", which i interpret to mean they can be added to the queue even if they have no valid targets to pick when they're added.

all three of these abilities can be added to the ability queue and resolved in what ever order you add them. they have to added to the queue at the same time, though.

Ignore.

Ignore.

5 hours ago, meffo said:

there is not any proper consensus on this, even though i think it's clear.

the whole ability queue must be built at the same time, in this scenario at the start of the engagement pase. my interpretation is that the only one of these three abilities that has an ability's requirement is unkar plutt's. his ability is also mandatory.

0-0-0 and ketsu both have abilities that state "you may choose", which i interpret to mean they can be added to the queue even if they have no valid targets to pick when they're added.

all three of these abilities can be added to the ability queue and resolved in what ever order you add them. they have to added to the queue at the same time, though.

Further to this, FFG provided some clarification around what is required to add an ability to the queue in the Official Rulings thread :

Quote

Q: What is meant by a "requirement" for an ability?

A: A requirement for an ability is a conditional if-statement, such as "if you are tractored" or "if the defender is in your bullseye arc." A ship being in-arc at range for an attack made as part of a triggered ability, such as Snap Shot or Foresight, is also a requirement for that ability.

If an ability's requirements are not met at the time the ability would be added to the queue, it cannot be added to the queue.

If the ability's requirements are not met at the time the ability would be resolved from the queue, the ability is not resolved and is instead removed from the queue.

If an ability instructs you to make a choice, such as choosing a ship, that is not itself a requirement to initiate an ability. [Emphasis added]

Ketsu and 0-0-0 both have the "you may choose" wording, which seems to fall under the last stipulation - choosing a ship is not a requirement, therefore they both go on the queue at the start of engagement and you choose a target when they resolve.

Sooooo, I thought the whole Old T and Ketsu trick didn’t work anymore??? This is essentially the same thing...

Does it still???

23 minutes ago, JBFancourt said:

Sooooo, I thought the whole Old T and Ketsu trick didn’t work anymore??? This is essentially the same thing...

Does it still???

It does.

46 minutes ago, JBFancourt said:

Sooooo, I thought the whole Old T and Ketsu trick didn’t work anymore??? This is essentially the same thing...

Does it still???

Well, there was a consensus on the forum after the initial "meet all requirements" timing ruling where the community leaned toward strict interpretation of requirements that included any direction to make a choice. Later we got the official FFG ruling referenced by Ysenhal where they actually defined what a requirement is, and making a choice is specifically listed as not being a requirement.

So here's Old T with that ruling in mind:

Since his ability is based on "you may choose" it can be added to the Queue without checking for valid targets, then when it resolves you do check for targets.

7 hours ago, meffo said:

there is not any proper consensus on this, even though i think it's clear.

the whole ability queue must be built at the same time, in this scenario at the start of the engagement pase. my interpretation is that the only one of these three abilities that has an ability's requirement is unkar plutt's. his ability is also mandatory.

0-0-0 and ketsu both have abilities that state "you may choose", which i interpret to mean they can be added to the queue even if they have no valid targets to pick when they're added.

all three of these abilities can be added to the ability queue and resolved in what ever order you add them. they have to added to the queue at the same time, though.

One notable thing to add here... when a particular timing trigger arrives (in this case, "At the start of the engagement phase"), then ALL of the abilities that would possibly trigger, need to be added to the queue. This includes both friendly and enemy triggers, added in player order.

This can come into play for effects like Snap Shot/Foresight and Fine Tuned Controls... if my (first player) foresight ship lands a shot on the opponent's (second player) jedi starfighter, I have to choose whether or not to queue Foresight, THEN my opponent can choose to queue Fine-Tuned Controls... if the opponent chooses to not queue it at that time, they cannot subsequently activate it later, as the triggering event (after fully executing a maneuver) has already passed.

Thx. guys. Also for adding to Old T example as I wasn't aware that 'consensus' had changed.

I considered adding 'Swarm Tactics' to Ketsu so it can use it's initiative on an friendly ship that happend to be tractored into range 1 of Ketsu at the start of the engagement phase.

BTW - Does this also means that 'Ensnare' can cascade again the tractor token? Probably not since if you cascade the tractor token to another Nantex that Nantax is either already tractored by its own ship ability or it is not tractored at the end of the Activation Phase.

For refernce Ensnare says - 'At the end of the Activation Phase, if you are tractored, you may choose 1 ship in your arc at range 0-1. Transfer 1 tractor token to it. '

9 minutes ago, Slade said:

BTW - Does this also means that 'Ensnare' can cascade again the tractor token? Probably not since if you cascade the tractor token to another Nantex that Nantax is either already tractored by its own ship ability or it is not tractored at the end of the Activation Phase.

You got it right. Because Ensnare has the 'start of activation' trigger followed by ' if you are tractored' the tractored status is a requirement of entering the ability queue.

I think I’m starting to understand... thank you 🙏

18 hours ago, emeraldbeacon said:

One notable thing to add here... when a particular timing trigger arrives (in this case, "At the start of the engagement phase"), then ALL of the abilities that would possibly trigger, need to be added to the queue. This includes both friendly and enemy triggers, added in player order.

I call this the 'pre-Queue' since you have to have all optional triggered abilities opt-in or opt-out and all abilities declared in order before any of them can be activated.

From my point of view, I'd say it doesn't work.

Trying to parse exactly what a "requirement" means is tricky stuff, and I have no idea whether it's right. I don't really find requirements to be all that well-defined, and have no clue how FFG would rule it.

So I think the best way to proceed is to treat things as simply as possible. If you want to enter something into the queue, you have to be able to do everything on the card at that time. Just seems like the safest way.

32 minutes ago, theBitterFig said:

Trying to parse exactly what a "requirement" means is tricky stuff, and I have no idea whether it's right. I don't really find requirements to be all that well-defined, and have no clue how FFG would rule it.

Yeah I originally thought that targeting was in requirement, but it's not. The reason we know this is in appendix example 2.

The trigger requirement for the two is "At the start of the Engagement Phase...", the range restrictions happen the moment you trigger the ability itself, hence looking for targets. 0-0-0 does not need a ship at range 0-1 when adding it to the queue, but it does need one when it's time comes to activate it from the queue.

19 hours ago, theBitterFig said:

Trying to parse exactly what a "requirement" means is tricky stuff, and I have no idea whether it's right. I don't really find requirements to be all that well-defined, and have no clue how FFG would rule it.

Which is why I was grateful for the list we did get on the FFG Official Rulings thread:

Which just says that 'if' statements are requirements (and arc/range for triggered attacks) which would count against Old T, Ketsu, Unkar, et al. Except that they close that post with this line (posted earlier by @Ysenhal :

"If an ability instructs you to make a choice, such as choosing a ship, that is not itself a requirement to initiate an ability."

Since the 'if' statement on Old T, Ketsu, et al. Is dependent on making a choice it is my understanding that the 'choice exception' I quoted takes precedence over the subsequent 'if' requirement. Operating under that interpretation means you can enter the queue without checking range/arc as long as the 'if' statement is dependent on making a choice first.

Man. This still boggles my mind. I tend to read text but in the end really need examples to make the words click so thx. all for chimming in.

13 hours ago, nitrobenz said:

Since the 'if' statement on Old T, Ketsu, et al. Is dependant on making a choice it is my understanding that the 'choice exception' I quoted takes precedence over the subsequent 'if' requirement. Operating under that interpretation means you can enter the queue without checking range/arc as long as the 'if' statement is dependant on making a choice first.

If statement... dependent on... choice exception... takes precedence... subsequent if requirement...

I'm not saying you're wrong. Heck, there's a solid chance you're right. But it's a mess . One of FFG's own making. I don't find FFG's own descriptions of what requirements are particularly useful. I don't know if they're better or worse than FFG's "ignore, but don't fully ignore, the obstacle" stuff. In practice, I can deal with the obstacle stuff, but I maintain that FFG's rulings don't actually make sense. They wanted to have their cake and eat it too, and came up with a ruling to do that. There's no real logic to it, it's all "because I said so."

I kinda see the queue stuff the same way. Somethings may or may not be requirements for really narrow technical distinctions which I still don't think are that well-defined, and it's not really something that can be understood without a lot of digging in. Particularly since FFG's technical writing isn't very consistent.

So that's why my preference is for a really simple test. Can you do the ability right now , without changing stuff first? If yes, then you can add it to the queue. Next, when it comes time to resolve the ability, you still have to be able to do it (stuff can't have moved out of range or arc or whatever). The main thrust of the ruling, at least to me, seemed to be FFG clamping down on "I'll do one thing, to trigger another thing, to trigger some third thing." To avoid long chains of abilities where at some point the "requirements" no longer apply.

Now, that's my preference , not my ruling . The whole point is to easily enable folks to play this game with each other. I don't really think the lengths to which we have to parse out what is and isn't a requirement gets us there. Some of that is a feeling that FFG could easily issue a new ruling which undercuts our understanding. Seems like they've done a lot more of that in 2e than before.

However, a quick and dirty check of "If you can't do it right now, you don't meet the requirements" is something I think most folks at the FLGS could easily understand and not have to come back to the forums for long debates about.

But that's all, like, just my opinion, man.

1 hour ago, theBitterFig said:

I'm not saying you're wrong. Heck, there's a solid chance you're right. But it's a mess . One of FFG's own making. I don't find FFG's own descriptions of what requirements are particularly useful. I don't know if they're better or worse than FFG's "ignore, but don't fully ignore, the obstacle" stuff. In practice, I can deal with the obstacle stuff, but I maintain that FFG's rulings don't actually make sense. They wanted to have their cake and eat it too, and came up with a ruling to do that. There's no real logic to it, it's all "because I said so."

100% agree with your feelings on this BitterFig. If it wasn't for the precedent set by the 'have your cake and eat it too' way that ignoring obstacles works I might have argued that the 'if' statement superceded its preceding choice directive.

1 hour ago, theBitterFig said:

However, a quick and dirty check of "If you can't do it right now, you don't meet the requirements" is something I think most folks at the FLGS could easily understand and not have to come back to the forums for long debates about.

'if you can't fully execute, then you can't add to the queue' was the lean of consensus that I saw after the 'meet all requirements ruling' until the more recent 'list of requirements ruling', and I agree that it's the simpler way to arrange the queue. Either way this needs to be outlined in the Rules Reference. "Official Rulings" are convenient ammunition for forum warriors, but not for live players, particularly when they run counter to common sense (or worse: run counter to existing rules!)

Queues, pre-queues, and stacks are not such common game mechanics that a developer should be able to assume players know how to navigate it without direction. It doesn't help that every game using a queue/stack treats it differently 😑