I am struggling to understand the "ability queue" - particularly, what the "back" of the queue is and what the "front" of the queue is. The new Rules Reference document did more to confuse me than it did to enlighten me on how the queue affects timing windows. If anyone can give me a parallel to LIFO (Last in, First out) terminology, I'd appreciate it. From what I can understand, if there are two or more effects being applied, they go in the queue by 1) player choice if they are the same player's effects at the same timing window, 2) player order if they are effects applied by different players at the same timing window. However, if one's a replacement effect, it will immediately trigger, but if it's a unique, applied effect, it has to line up in the queue at the "back", which means that it may not resolve if its conditions aren't met by the time it gets to the front of the queue. In addition, if a triggered effect's conditions aren't met during the time they could be met (i.e. the tractor example), the effect can't be applied. Is this correct?

The ability queue is a queue. It is FIFO first in, first out. Just like wating at line at your favorite coffee shop.

Maybe I am wrong here but an ability cannot be added to the queue if it is not met, even if it would be met by the time it is at the front

I think my confusion is more about the multiple triggered instances of a single ability.

It's a bit of a hybrid queue and stack.

I can't actually think of any time something is added to the back of the queue except for when the queue is empty in which case the back and front are the same thing. When you add multiple abilities to the queue you add them in the order they resolve instead of in the opposite order like you would with a stack (though since it is an imaginary queue, you aren't actually adding them in any order just remembering the order to resolve them).

If an effect from an ability triggers another ability it is added to the front of the queue, just like how a stack operates.

3 minutes ago, joeshmoe554 said:

I can't actually think of any time something is added to the back of the queue except for when the queue is empty

Do you mean front? Items are always added to the back.

RR pg 3

Quote

Abilities are resolved from the front of the queue to the back of the queue. These abilities are added to the back of the ability queue using the following rules:

3 minutes ago, Lyianx said:

Do you mean front? Items are always added to the back.

RR pg 3

Except that anything triggered by an ability in the queue is added to the front. In what case would something be added to an existing queue without being triggered by an effect in that queue?

17 minutes ago, joeshmoe554 said:

Except that anything triggered by an ability in the queue is added to the front. In what case would something be added to an existing queue without being triggered by an effect in that queue?

Thats why i was confused by your statement. Abilities can be added to the front or the back, depending on the timing.

So on the one hand, we have.

Quote

Abilities are resolved from the front of the queue to the back of the queue. These abilities are added to the bac k of the ability queue using the following rules:

and on the other, we have ..

Quote

If resolving an effect from the ability queue triggers additional effects, they are added to the front of the ability queue using the above rules.

Just saying that for the 'fresh queue', ability's are constantly added to the back until no more abilities can/will be added. Sorry if that sounds weird as i took your "except when empty" to mean completely empty in that moment.

Also, even when adding "to the front" they are still done by player order, so it doesnt need to be empty to add to the back, as if both players have abilities from "triggers additional effects" player 2's will be added behind player 1's (ie, not the front).

:P

lets have a look at it! it's bloody well needed at this point in time.

Quote

ABILITY QUEUE

The ability queue is used to resolve the timing of multiple abilities that trigger during the same timing window. Abilities are resolved from the front of the queue to the back of the queue. These abilities are added to the back of the ability queue using the following rules:

1. If both players have abilities that triggered from the same event, the abilities are added to the ability queue in player order.

2. If a player has multiple abilities that triggered from the same event, that player chooses the order that those abilities are added to the ability queue.

3. If resolving an effect from the ability queue triggers additional effects, they are added to the front of the ability queue using the above rules.

See Appendix for 2 examples of the ability queue.

• If there are game effects that share the same timing window as a player’s ability, the game effect is resolved first.

◊ For example, if a ship performs a red barrel roll and the ship has an ability that triggers after it performs a barrel roll, the ship gains a stress token before the other ability is resolved.

• 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.

• If a ship would be removed while there are one or more abilities in the queue, do not remove that ship until there are no abilities in the queue.

ok, it's used to resolve abilities that have the same timing window. it is resolved from front to back. abilities are added to the back of the queue - and resolved from the front. if you want to add abilities to the queue, you have to start with the one you want to resolve first, then the one you want to resolve after that, then the one you want to resolve after that - and so on.

effects that are not abilities are always resolved immediately and are not added to the queue. player order determines which player adds their abilities first (and therefore, which player resolves their abilities first) and which player adds their abilities to the queue after that. if a player is resolving an ability and that triggers another ability (no matter who owns it), that ability or effect always resolves immediately after the current ability in the queue has resolved, since that ability is added to the front of the queue.

again, effects that are not abilities are always resolved first, even if that happens in the middle of an ability being resolved.

now we get to the juicy new part, which sets up a whole new bunch of circumstances for how we can handle the ability queue. basically, you cannot add abilities to the queue while the queue is being resolved, unless it's an ability triggered by an effect or ability in the queue resolving. timing windows are now short, "at the end of the activation phase" is now one instance where the queue is built up, that ends as soon as the queue has started to resolve.

in short, the requirements (also not a defined game term, which causes a lot of problems currently) for an ability have to be met for it to enter the queue at the giving timing. unfortunately, we don't know what is considered a requirement in all cases. is not being stressed a requirement for adding an ability to the queue that lets you perform an action? is a ship that has just executed a maneuver being in arc and range of snap shot or foresight a requirement for us to add snap shot or foresight to the queue - or can we add them and see if other effects in the queue will put them in range and arc?

and lastly, if a ship would be removed while an ability queue is being resolved, do not remove it before the queue is empty.

1 hour ago, Lyianx said:

Do you mean front? Items are always added to the back.

RR pg 3

1 hour ago, joeshmoe554 said:

Except that anything triggered by an ability in the queue is added to the front. In what case would something be added to an existing queue without being triggered by an effect in that queue?

And now my confusion becomes apparent! As is evident from these posts, there's some other people who are having issues as well. Thanks for the input so far; hopefully we can figure this out to everyone's satisfaction.

A lot of it comes down to perspective. The important things to know are the 3 points listed.

• If both players have abilities that triggered from the same event, the abilities are added to the ability queue in player order.
• If a player has multiple abilities that triggered from the same event, that player chooses the order that those abilities are added to the ability queue.
• If resolving an effect from the ability queue triggers additional effects, they are added to the front of the ability queue using the above rules.

The new elements are just that an ability cannot enter the queue if the "ability requirements" are not met when that ability is triggered, but there seems to be some confusion as to what an ability requirement is. And that any ability in the queue will resolve even if the ship that added it is destroyed before that ability would resolve.

So, what we've learned today:

• Abilities get added to the back of the ability queue, unless they get added to the front
• An ability can only be added to the queue if it can be added to the queue

Instead of thinking it as the front of the queue, it is like a sub queue that got made from something in the original queue.

Queue is just a fancy way of saying a line.

Taking a few specific use cases might make it easier to process.

16 hours ago, meffo said:

1. If both players have abilities that triggered from the same event, the abilities are added to the ability queue in player order.

A good example is Assaj Ventress and "Muse" - both have a start-of-engagement-phase ability, one lets you apply a stress token to an enemy ship, one to let you remove a stress token from a friendly ship.

"Muse" has no requirements associated with her ability in terms of tokens, or 'a ship in your arc' or whatever to trigger it - it always happens at the start of the engagement phase. But if she's before Assaj in the queue, there'll be no stressed ship within range 0-1 to select. If she's after Assaj in the queue, there will be, and Assaj's stress token goes to waste.

16 hours ago, meffo said:

2. If a player has multiple abilities that triggered from the same event, that player chooses the order that those abilities are added to the ability queue.

A logical example here is Advanced Targeting Computer. It lets you modify one hit to critical in the modify dice step if you have the target locked. If you have the target locked, you also have the ability to spend that lock to reroll any number of attack dice.

Obviously, you would modify a hit to a crit first, because after you spend the lock to reroll, you no longer have the target locked and Advanced Targeting Computer's requirement to trigger isn't met.

16 hours ago, meffo said:

3. If resolving an effect from the ability queue triggers additional effects, they are added to the front of the ability queue using the above rules.

This is probably most commonly important when the effect is paying a cost or receiving a critical effect. Whilst you're building the queue, stuff is added to the front of the queue. Whilst it's resolving, stuff is added to the front.

16 hours ago, meffo said:

• If there are game effects that share the same timing window as a player’s ability, the game effect is resolved first.

This one actually has an example.

16 hours ago, meffo said:

• If an ability’s requirements are not met, it cannot be added to the ability queue.

So does this. As another example, you can't use fine-tuned controls to 'jiggle' your bullseye a bit then use an "after you execute a manoeuvre, if someone is in your bullseye" trigger after you've started resolving the 'after you execute a manouvre' queue.

16 hours ago, meffo said:

• If a ship would be removed while there are one or more abilities in the queue, do not remove that ship until there are no abilities in the queue.

If this wasn't a thing, then 'when this ship is destroyed' abilities would be almost impossible to use.

11 hours ago, Amc879 said:

Instead of thinking it as the front of the queue, it is like a sub queue that got made from something in the original queue.

Queue is just a fancy way of saying a line.

Yep. A very British way.

On 9/19/2019 at 10:17 AM, joeshmoe554 said:

• If both players have abilities that triggered from the same event, the abilities are added to the ability queue in player order.
• If a player has multiple abilities that triggered from the same event, that player chooses the order that those abilities are added to the ability queue.
• If resolving an effect from the ability queue triggers additional effects, they are added to the front of the ability queue using the above rules.

I think it's critical to note that for purposes of the third point as the Queue progresses the "front" is somewhere in the middle of the original Queue.

For example, a trigger occurs and results in a total of five abilities, then the third ability triggers two additional abilities. The total Queue of all triggered abilities would look like this:

1, 2, 3, 3a, 3b, 4, 5

Think of it as resolved abilities have left the Queue, so whatever stage you're at is currently "the front" and freshly triggered abilities are taken care of before proceeding with the original list.

Is there anything is this game that would TOTALLY be effected/altered drastically by how and when it resolves during any given phase? In other words, in MTG, for example, if the stack didn’t exist then first strike, killing a creature before you accept damage and tons of other effects would never work. It always had to be, player A does something and Player B is given priority to react and so on. In X-WING it doenst seem to be so strict in that regard. Theres no “instants”, so to speak that, so...there’s no surprises or secrets, I mean. I’m rambling now...

The given example of Snap Shot vs Afterburner boost could drastically alter the state of a game by destroying an ace before it escapes the attack.

For example: Vader (an expensive core member of many Ace type lists) flown by player 1 can use Afterburners to get from range 2 to range 1 before an enemy Green Squadron A-wing with Snap Shot resolves then annihilate the A-wing at i6 before it gets too use the regular attack. On the other side, if Vader is already damaged and flown by player 2 there is a real possibility that Snap Shot would have killed Vader before his Afterburner boost which not only destroys Vader but by extension saves the A-wing.

The end result of that example demonstrates a potential of around 100 points swing in the score by combining the saved ship and lost ship values. And all predicated on who is player 1 or player 2.

15 hours ago, nitrobenz said:

The given example of Snap Shot vs Afterburner boost could drastically alter the state of a game by destroying an ace before it escapes the attack.

For example: Vader (an expensive core member of many Ace type lists) flown by player 1 can use Afterburners to get from range 2 to range 1 before an enemy Green Squadron A-wing with Snap Shot resolves then annihilate the A-wing at i6 before it gets too use the regular attack. On the other side, if Vader is already damaged and flown by player 2 there is a real possibility that Snap Shot would have killed Vader before his Afterburner boost which not only destroys Vader but by extension saves the A-wing.

The end result of that example demonstrates a potential of around 100 points swing in the score by combining the saved ship and lost ship values. And all predicated on who is player 1 or player 2.

I've actually experienced some of the difficulty of Snap Shot interrupting actions, which is part of the reason for my confusion. The player I was flying against triggered Snap Shot as soon as I moved into Range 2, before I could perform any actions, so I can see how your Vader example works (although I don't remember who had Player 1 in that game).

18 hours ago, nitrobenz said:

The given example of Snap Shot vs Afterburner boost could drastically alter the state of a game by destroying an ace before it escapes the attack.

For example: Vader (an expensive core member of many Ace type lists) flown by player 1 can use Afterburners to get from range 2 to range 1 before an enemy Green Squadron A-wing with Snap Shot resolves then annihilate the A-wing at i6 before it gets too use the regular attack. On the other side, if Vader is already damaged and flown by player 2 there is a real possibility that Snap Shot would have killed Vader before his Afterburner boost which not only destroys Vader but by extension saves the A-wing.

The end result of that example demonstrates a potential of around 100 points swing in the score by combining the saved ship and lost ship values. And all predicated on who is player 1 or player 2.

Yes. Not seeing the problem there. This is why you spend points on initiative.

This whole thing certainly suggests the "must do" effects and "may do" effects and when abilities become "game effects" and how those must enter the queue clarifications I was recommending in another thread weren't that bad an idea.

4 hours ago, Frimmel said:

Yes. Not seeing the problem there. This is why you spend points on initiative.

This whole thing certainly suggests the "must do" effects and "may do" effects and when abilities become "game effects" and how those must enter the queue clarifications I was recommending in another thread weren't that bad an idea.

No problem suggested. That was an example for @K-2SO who asked in the post above if there was anything that would drastically alter the game state depending on order of the Ability Queue.

I'm always in favor of more clarifications, especially when something is treated as a keyword the way "game effect" and "player ability" are.