My head is too tired to answer this on the wiki right now, so I'd love some help.

Q: Did the new ability queue ruling wreck the combo of DFS-311 passing a token to DBS-32C to allow the coordinate?

My first reaction is the combo is dead now because 32C cannot add its ability to the queue without a calc token, but maybe I'm missing something (e.g. whether the calc token is a "requirement")... I've been writing code all day and my head cannot brain anymore, and the ability queue stuff isn't always simple. :/

Original question from the DBS-32C page:

Quote

So doing a list planning and ran into a question. Does DFS passing a token to DBS count to still able to DBS to trigger ablity?

DFS abltity: At the start of the Engagement Phase, you may transfer 1 of your calculate tokens to another friendly ship at range 0-3.

From rule update SEPT: 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 uponits 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.

I am unsure if it would kick in since it was a token as appose to effect like tractor just feeling out how others are jibin it being read. VR

Thanks, everyone!

I'd say the new Rules Ref/requirements rule blocks it. I'm not 100% sure, but that seems to be the spirit of the rule.

No, it doesnt block it. 32C's abiltiy doesnt require him to have the token to queue the ability. Otherwise it would say "if you are calculating.."

i agree with @Lyianx . but there is no way to be sure as of right now. we have to wait for a rules update, since there is still confusion about what constitutes an ability's requirement.

until then (and hopefully not after that), it's TOs discretion.

based on the RAW right now, there is no indication the whole ability has to be able to resolve at the time you add it to the queue - and as the wording does not include an "if you are calculating" or similar wording, adding it to the queue at the beginning of engagement is fine in my opinion.

Combo reads like it works to me. There are no requirement conditions modifying either timing clause, so as long as 32C is processed second (and was in range 0-3 of 311 so it could get the calc token in the first place) Butter bot can fuel 32C's coordinate.

So it's very similar to Snap Shot (it depends on whether "able to attack that target right now" or "has a token to spend" is counted by FFG as a requirement, vs stuff like "if you are tractored"). We still very much need FFG to clarify what's a requirement, and until then, it's ambiguous but arguably allowed... depending on where your TO falls.

Thanks, all!

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 <bullseyearc>." 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 instruct you to make a choice, such as choosing a ship, that is not itself a requirement to initiate an ability.

Seems like a confirmation that this combo still works. Calculate token is not a requirement to be added to the ability queue.


Aannd then they quickly contradict themselves, again.

Quote

Q: When is the cost for an ability paid?

A: The cost for an ability is paid when the ability is resolved.

An ability cannot be added to the queue if its cost could not be paid at the time it is added.

If an ability's cost cannot be paid when it would be resolved from the queue, the ability is not resolved and is instead removed from the queue. The ability's cost is not paid.

An ability can have multiple costs. If it does, all costs must be paid to resolve it. If all costs cannot be paid, no costs are paid and the ability is removed from the queue and not resolved.

So guess its back to not working.

Yeah, this whole thing is turning into a serious mess. You basically have to meet the requirements and be able to pay the costs at two different times in order to resolve an ability. This is just about certain to create all kinds of unintended nerfings and lots of confusion as combos which used to work no longer do.

Heyo so i'm the original asked on the Fandom. I figure it is still just a side victim of rule change. Just like DFs pas cal to Discord user. Thanks all for the input.

3 hours ago, gamblertuba said:

Yeah, this whole thing is turning into a serious mess. You basically have to meet the requirements and be able to pay the costs at two different times in order to resolve an ability. This is just about certain to create all kinds of unintended nerfings and lots of confusion as combos which used to work no longer do.

I dunno.

I think FFG's goal in all of this is to eliminate any sorts of chains of abilities. If you can do the whole ability right now, without any help from other abilities, you can. If you can't do the ability right now, if you need to adjust range or tokens or so forth, then it doesn't matter if you do those adjustments, the time has passed.

If we forget about trying to precisely work out what exactly is a requirement, if DBS-32C doesn't have a calculate token, they can't do their ability. If DFS-311 passes one along, well, it's too late. I think that's a really clean way of looking at things, even though it's not technical.

Seems to line up how they've been ruling on stuff, like a ship can FTC out of Snap Shot, but can't FCS into Snap Shot, or the stuff on costs (have to be able to pay it at both time of entry to queue, as well as time of resolution).

14 hours ago, theBitterFig said:

I dunno.

I think FFG's goal in all of this is to eliminate any sorts of chains of abilities. If you can do the whole ability right now, without any help from other abilities, you can. If you can't do the ability right now, if you need to adjust range or tokens or so forth, then it doesn't matter if you do those adjustments, the time has passed.

If we forget about trying to precisely work out what exactly is a requirement, if DBS-32C doesn't have a calculate token, they can't do their ability. If DFS-311 passes one along, well, it's too late. I think that's a really clean way of looking at things, even though it's not technical.

Seems to line up how they've been ruling on stuff, like a ship can FTC out of Snap Shot, but can't FCS into Snap Shot, or the stuff on costs (have to be able to pay it at both time of entry to queue, as well as time of resolution).

This is probably the most sensible reading of what the many, many ability queue "clarifications" are trying to accomplish. I'd go with this interpretation over many of the others, as it also makes sense in my approach to the game.

19 hours ago, gamblertuba said:

Yeah, this whole thing is turning into a serious mess. You basically have to meet the requirements and be able to pay the costs at two different times in order to resolve an ability. This is just about certain to create all kinds of unintended nerfings and lots of confusion as combos which used to work no longer do.

It changes things, but it's probably less messy than it was before. This update reduces the overall complexity of interactions.

1 hour ago, svelok said:

It changes things, but it's probably less messy than it was before. This update reduces the overall complexity of interactions.

I disagree, I think making ability requirements only apply to explicit requirements meaning any if statement before describing the actual ability (typically everything after "you may") is much cleaner than also sometimes including implicit requirements such as attack requirements or cost requirements.

Also, making requirements apply to both trigger the ability and resolve the ability requires checking those requirements multiple times for the same ability which is cumbersome and messy. I imagine the ruling could have been worse, but this is far from being "less messy" than it was.