Timing and measuring range (Nephilim example)

[Ludvig]

A terror tot is killed. Nearby it is a young nephilim. The terror tot's ability Brood resolves first but when do you measure the range for the Thirst for blood of the young nephilim, before or after moving due to brood? This has implications for other abilities as well like start of activation auras.

 

Brood: When this model is killed, all friendly Nephilim within 6" and LoS of it may immediately take a Walk Action directly toward the model that killed this model.

Thirst for blood: This model receives Fast when a non-Construct model within 3" is killed by another friendly model.

[Kadeton]

9 hours ago, Paddywhack said:

So, to be clear, you're saying that it won't trigger both abilities as you count the trigger from the moment the model is killed. At that moment only the brood ability is in range. Once you have moved the model you have passed the 'model is killed' point and can't still trigger Thirst for Blood?

I'm just trying to be clear as I'm reading both interpretations and want to be sure I'm thinking of the timing rules correctly. 

Yep, if the Young Nephilim wasn't within 3" of the Terror Tot when it died, it can't benefit from Thirst For Blood, even if Brood allows it to then move to within 3". Basically, for Abilities that have the same timing (in this case, the death of a model) they have to happen simultaneously or not at all.

[twibs]

Why would this differ from the general timing?

Acting -> Defending -> First player models -> Second player models.

I'm under the impression you resolve the whole ability (including move) before you resolve next. I'll need to double Check once home.

[Ludvig]

1 hour ago, twibs said:

Why would this differ from the general timing?

Acting -> Defending -> First player models -> Second player models.

I'm under the impression you resolve the whole ability (including move) before you resolve next. I'll need to double Check once home.

If a young neph wasn't within 3" at the time of death but then moves into that range it would then get fast? It's an age old discussion on if you check which auras apply at the time something happens and then resolve them in order or if you can change what is affecting you by moving during one of the steps. I'm not sure it's super clearly stated in the rulebook but I would love to see a page reference that could clear this up.

[twibs]

Page 58. Aura reads: Aura icon( ) appears as a part of a range for some actions or abilities. 

So basically aura is just an ability with limited range. Since your aura doesn't specify a time, wouldn't you be able to declare that ability when ever the conditions are fullfilled? I don't know, would this cause further complications?

[Kadeton]

2 hours ago, Ludvig said:

If a young neph wasn't within 3" at the time of death but then moves into that range it would then get fast? It's an age old discussion on if you check which auras apply at the time something happens and then resolve them in order or if you can change what is affecting you by moving during one of the steps. I'm not sure it's super clearly stated in the rulebook but I would love to see a page reference that could clear this up.

You might be overthinking this.

The death is the causal event for resolution of both abilities, but it's instantaneous. Each ability will resolve if, and only if, its requirements were met at the instant of death.

In the initial question, when the Tot dies, both abilities go off. The Young Nephilim would have to resolve Brood's effect before resolving Thirst For Blood (due to General Timing, since the Tot is the Defender and the Young Nephilim can't be the Acting Model) but it makes no difference if the Young Nephilim moves further than 3" from the Tot - the conditions for both abilities were met, so both will resolve.

In your follow-up quoted above, if the Nephilim wasn't within 3" of the Tot at the instant of its death, then Thirst For Blood would not meet the conditions necessary for it to happen. It doesn't matter whether the Nephilim moves within 3" as a result of Brood, as the instant of death has already passed.

I'm not sure what I could cite that would help further - all the necessary rules are right there in the Abilities, perhaps with reference to General Timing (p. 46 BRB).

[solkan]

I think what it comes down to is something Warmachine/Hordes refers to as the "recheck triggers" principle.

In Warmachine/Hordes, as you resolve effects, that resolution can invalidate that have been triggered and are waiting for resolution.  For example, two effects can be triggered by a model in step 2 of being killed.  If the first effect negates step 2 of being killed, then the trigger for the other effect is no longer valid and the effect won't be resolved.  Some instances of checking ranges in Warmachine/Hordes falls under the "recheck triggers" principle--the range for 'When a model within X is killed..." has to be satisfied when you resolve the effect--and other instances are just part of resolving the effect--for "all models within Y suffer a damage roll", you check which models are within Y when you resolve the effect.

Malifaux's rules (or, at least, 2nd edition rules) don't appear to be written using a "recheck triggers" principle.  So once an effect is queued up for resolution in General Timinf, it gets resolved.  But there still seems to be the two different types of ranges--the trigger range and the effect range.  

 

[Ludvig]

Thanks Solkan and Kadeton, that's what I was looking for. My silly trick will work

[twibs]

So to sum it up so that even the bit dafter (me) will understand.

1. An event happens (The death of the Terror Tot)
2. Declare viable abilities and form a stack(or chain or what ever you will call it) according to timing principles (Brood, Thirst for blood if it was close enough)
3. Resolve abilities according to the timing of the stack.

I may have played some MtG, so a "stack" is familiar to me.

[WWHSD]

So how do you determine exactly where a model was when a trigger occured if it's already been moved?

Do you resolve effects that were triggered on a model that was removed from play between when the effect was triggered and when the the effect would be resolved?

It seems like it's easier to handle resolving effects based on the game state that exists while you are resolving the effect than it is to determine all  possible effects that could trigger and gather all of the information needed to resolve all of the triggered effects at the time that the effect was triggered.

[Ludvig]

52 minutes ago, WWHSD said:

So how do you determine exactly where a model was when a trigger occured if it's already been moved?

Do you resolve effects that were triggered on a model that was removed from play between when the effect was triggered and when the the effect would be resolved?

It seems like it's easier to handle resolving effects based on the game state that exists while you are resolving the effect than it is to determine all  possible effects that could trigger and gather all of the information needed to resolve all of the triggered effects at the time that the effect was triggered.

The other way of doing it has you rechecking it all at later points which should lead to just as much measuring. The model died within 3" of thr young which should be easy to measure since you will already be measuring to see if you were within 3" and thus get a measurement. Then you resolve the effects from the new posiion but the effecr will still happen since you noted the range and concluded that you would resolve the ability after resolving the first one in order.

[Kadeton]

@WWHSD: To be clear, there are two aspects to a "triggered" Ability - the game state that causes it to be triggered, and the resolution of its effect.

If the triggering cause of the Ability would also cause other Abilities to trigger at the exact same time, then you resolve them all in the order determined by General Timing. However, each is resolved according to the current game state at the time of resolution - the order is important! The thing that you don't do is re-check the requirements that caused the Ability to trigger - that's already been determined.

So, to answer your questions:

8 hours ago, WWHSD said:

So how do you determine exactly where a model was when a trigger occured if it's already been moved?

You don't. You determine all the Abilities that are going to trigger as a result of a game event before resolving any of them, making any measurements necessary to check. You shouldn't be moving any models until after that point. For all the effects of the Ability as it's resolved, you measure from the model's current position at the time of resolution.

8 hours ago, WWHSD said:

Do you resolve effects that were triggered on a model that was removed from play between when the effect was triggered and when the the effect would be resolved?

This sort of depends. Many Abilities of that type have wording to the effect of "When this model is killed or sacrificed, but before it is removed from play..." in which case you'll resolve all those Abilities before removing the model. There are very few effects that would be relevant to resolve on a model after it has been removed from play.

8 hours ago, WWHSD said:

It seems like it's easier to handle resolving effects based on the game state that exists while you are resolving the effect than it is to determine all  possible effects that could trigger and gather all of the information needed to resolve all of the triggered effects at the time that the effect was triggered.

"Resolving effects based on the game state that exists while you are resolving the effect" is exactly what you should be doing, as is "determine all possible effects that could trigger... at the time that the effect was triggered." The bit that you don't need is "gather all of the information needed to resolve all of the triggered effects".

Hope that helps!

[Lokibri]

18 hours ago, Kadeton said:

You might be overthinking this.

The death is the causal event for resolution of both abilities, but it's instantaneous. Each ability will resolve if, and only if, its requirements were met at the instant of death.

In the initial question, when the Tot dies, both abilities go off. The Young Nephilim would have to resolve Brood's effect before resolving Thirst For Blood (due to General Timing, since the Tot is the Defender and the Young Nephilim can't be the Acting Model) but it makes no difference if the Young Nephilim moves further than 3" from the Tot - the conditions for both abilities were met, so both will resolve.

In your follow-up quoted above, if the Nephilim wasn't within 3" of the Tot at the instant of its death, then Thirst For Blood would not meet the conditions necessary for it to happen. It doesn't matter whether the Nephilim moves within 3" as a result of Brood, as the instant of death has already passed.

I'm not sure what I could cite that would help further - all the necessary rules are right there in the Abilities, perhaps with reference to General Timing (p. 46 BRB).

I think what Ludvig is referring to, is a problem that often occurs in other games too (Magic for example) when abilites are resolved.

The one thing you mentioned is: It is resolved instantly on the occurance of the event!

The thing Ludvig might have in mind is: it is resolved after some abilities activated and the others are "checked" on resolution.

This is what it is called "the stack" in magic. And it is quite unclear if there is something similar in Malifaux or not.

I can totally understand his confusion i have to admit.

[Kadeton]

4 hours ago, Lokibri said:

I think what Ludvig is referring to, is a problem that often occurs in other games too (Magic for example) when abilites are resolved.

The one thing you mentioned is: It is resolved instantly on the occurance of the event!

The thing Ludvig might have in mind is: it is resolved after some abilities activated and the others are "checked" on resolution.

This is what it is called "the stack" in magic. And it is quite unclear if there is something similar in Malifaux or not.

I can totally understand his confusion i have to admit.

There's (deliberately, from what I could gather from the previous lead designer) nothing so formal as Magic's "stack" in Malifaux. However, the General Timing rules inherently produce something quite similar to a stack, though Abilities generally do not "interrupt" or get added to the "top" of the stack.

One of the things that makes this quite difficult to talk about is the lack of terms available, because they're already taken as Game Terms with specific meaning. You can't really talk about an Ability being "triggered" or "activated", because Triggers and Activations are already defined. That can really add to the confusion, and make it tricky to communicate.

[Paddywhack]

12 hours ago, Kadeton said:

"Resolving effects based on the game state that exists while you are resolving the effect" is exactly what you should be doing, as is "determine all possible effects that could trigger... at the time that the effect was triggered." The bit that you don't need is "gather all of the information needed to resolve all of the triggered effects".

Hope that helps!

So, to be clear, you're saying that it won't trigger both abilities as you count the trigger from the moment the model is killed. At that moment only the brood ability is in range. Once you have moved the model you have passed the 'model is killed' point and can't still trigger Thirst for Blood?

I'm just trying to be clear as I'm reading both interpretations and want to be sure I'm thinking of the timing rules correctly. 

[twibs]

Wait, I can see some slight inconsistencies regarding the timing. Some previous question had to do about the timing of Bad JuJu's unbury and gupps "juvenile wail".

In a sense, the JuJu is not within the range of the wail at the time of the death, since it's buried, but depending on circumstances it can unbury before the wail is triggered. So, should we at the time of declaring abilities, also declare targers? In a sense the act of unbury will "place" the model there, but in that case what is the difference of resolving the wail before if the JuJu already "is" there?

To put it in other way:

Case 1: Model A is killed, which triggers model B to push towards it. Model B has aura which can be triggered by the death of model A. Model B cannot declare this ability if it wasn't within range at the time of death.

Case 2: Model A is killed, which triggers model B to push towards it. Model A has pulse which triggers at the time of his death. Model B CAN benefit from that pulse, since Model B pushed (or unburied) into range before the ability was resolved?

Is this right?

[Myyrä]

Despite what @Kadeton says there is actually zero evidence that timing for checking whether abilities should be resolved is actually different from the timing they are resolved.

Or to put it in another way that at least people who understand programming should grasp: It is not clear whether we should check which abilities are triggered and then loop through those in the right order, or if we should just loop through all the abilties in the right order and resolve them if they meet the conditions to be triggered.

[twibs]

I have to agree with Myyrä, with the current rules we cannot decipher the RAW or RAI of this scenario.

For sake of simplicity, which the game at times seems to thrive for, we could declare and resolve them one by one, even though this might cause some "real life" inconsistencies.

[Kadeton]

2 hours ago, twibs said:

Wait, I can see some slight inconsistencies regarding the timing. Some previous question had to do about the timing of Bad JuJu's unbury and gupps "juvenile wail".

In a sense, the JuJu is not within the range of the wail at the time of the death, since it's buried, but depending on circumstances it can unbury before the wail is triggered.

I'm not familiar with this question or that version of the answer - it's not how I'd expect those abilities to resolve. Was this from the official FAQ?

1 hour ago, Myyrä said:

Despite what @Kadeton says there is actually zero evidence that timing for checking whether abilities should be resolved is actually different from the timing they are resolved.

Or to put it in another way that at least people who understand programming should grasp: It is not clear whether we should check which abilities are triggered and then loop through those in the right order, or if we should just loop through all the abilties in the right order and resolve them if they meet the conditions to be triggered.

I disagree. The General Timing rules provide a way to order a list of simultaneous abilities - "If two Abilities happen at the same time, resolve them in the following order". Note that it does not say, "When an event occurs, check each model in play in the following order, and resolve any relevant Abilities," which would produce your second "loop". You are expected to have already formed a list of relevant abilities based on the event that occurred; you then resolve them in the order provided. How do you form that list, if not to check the criteria of abilities at the time of the event?

[twibs]

The question in question (ba-dum-tsih) is one asked on this same forum, actually only few topics below this one.

But should models be excluded from pulse effects, if they were outside of it at the occurance of the event?

[Kadeton]

21 minutes ago, twibs said:

The question in question (ba-dum-tsih) is one asked on this same forum, actually only few topics below this one.

But should models be excluded from pulse effects, if they were outside of it at the occurance of the event?

I'll check it out.

One thing to be clear about is what the event is in this case. The death of the Gupp is the event that causes both Mud Calling and Juvenile's Wail to be resolved. If the Gupp was the Defender in the Action that killed it, Juvenile's Wail would have to be resolved before Mud Calling. If it wasn't (if it was killed by blast damage, for example) then the Neverborn player could choose to resolve Mud Calling first, then Juvenile's Wail - note that the pulse is part of the resolution of Juvenile's Wail, not part of its timing.

[Myyrä]

3 hours ago, Kadeton said:

I disagree. The General Timing rules provide a way to order a list of simultaneous abilities - "If two Abilities happen at the same time, resolve them in the following order". Note that it does not say, "When an event occurs, check each model in play in the following order, and resolve any relevant Abilities," which would produce your second "loop". You are expected to have already formed a list of relevant abilities based on the event that occurred; you then resolve them in the order provided. How do you form that list, if not to check the criteria of abilities at the time of the event?

In fact, the rules don't say anything about forming any lists. There is nothing there supporting forming a list of abilities and triggers caused by some event. One could just as easily argue that the general timing says that you should check all abilities and triggers on all models in the provided order and resolve the ones that have their triggering conditions met.

[Kadeton]

1 hour ago, Myyrä said:

In fact, the rules don't say anything about forming any lists. There is nothing there supporting forming a list of abilities and triggers caused by some event. One could just as easily argue that the general timing says that you should check all abilities and triggers on all models in the provided order and resolve the ones that have their triggering conditions met.

To continue your programming analogy, "If two Abilities happen at the same time, resolve them in the following order" is a compare function. The only way to use such a thing in this context is to run it over a set of data, producing an ordered list.

Looking at it another way, the only way you can possibly tell "if two Abilities happen at the same time" is if you know which abilities are happening at that time. You need to know if before you determine the order, according to the way the rule is written.

I would like to see your argument that the order given is applied to all models, rather than to the abilities that are happening at the same time, based on the structure of that sentence.

[Myyrä]

55 minutes ago, Kadeton said:

To continue your programming analogy, "If two Abilities happen at the same time, resolve them in the following order" is a compare function. The only way to use such a thing in this context is to run it over a set of data, producing an ordered list.

But Malifaux isn't a computer program, and even if it were, claiming that that is the only way to understand that sentence and that is the only possible order of doing the comparisons only shows lack of imagination.

Quote

Looking at it another way, the only way you can possibly tell "if two Abilities happen at the same time" is if you know which abilities are happening at that time. You need to know if before you determine the order, according to the way the rule is written.

 That might be sort of true if we were talking about computer program, but we aren't, and even if we were, the thing is so ambiguously written that it's impossible to determine whether that part is part of the algorithm of determining the timings or a check for whether you should start running the algorithm.

Quote

I would like to see your argument that the order given is applied to all models, rather than to the abilities that are happening at the same time, based on the structure of that sentence.

The burden of proof usually rests on the one who claims he knows something the rest of us do not.

[Kadeton]

6 hours ago, Myyrä said:

Or to put it in another way that at least people who understand programming should grasp: It is not clear whether we should check which abilities are triggered and then loop through those in the right order, or if we should just loop through all the abilties in the right order and resolve them if they meet the conditions to be triggered.

I suggest you don't reference programming if you're not prepared to follow through with that paradigm. As you say, "Malifaux isn't a computer program," but my use of programming to explain the situation was merely following on from yours - if you'd prefer a different frame of reference, name it. I've also approached the problem from a semantic perspective in what I've said above, if you prefer.

33 minutes ago, Myyrä said:

claiming that that is the only way to understand that sentence and that is the only possible order of doing the comparisons only shows lack of imagination

the thing is so ambiguously written

Perhaps I lack imagination. I don't think the sentence is particularly ambiguous, and I think the explanation in FAQ #88 makes it as clear as it needs to be. You've asserted the opposite, but you haven't actually put forward any evidence to support that. Would you care to?

Quote

The burden of proof usually rests on the one who claims he knows something the rest of us do not.

I've explained my reasoning in detail. If you need clarification on any part of it, I'm happy to answer questions. If you've got counter-arguments, I'm happy to hear them and discuss them. But if all you've got is "Nuh uh!" then I'm not really interested in engaging further, and to be honest I'm not sure why you are either.

[Myyrä]

9 minutes ago, Kadeton said:

I suggest you don't reference programming if you're not prepared to follow through with that paradigm. As you say, "Malifaux isn't a computer program," but my use of programming to explain the situation was merely following on from yours - if you'd prefer a different frame of reference, name it. I've also approached the problem from a semantic perspective in what I've said above, if you prefer.

I used the analogy to highlight how the text in the book is consistent with two different algorithms, because unlike the rules of Malifaux or English language, algorithms are unambiguous. That doesn't mean that you can suddenly claim that the rules can be read as if they were an algorithm.

9 minutes ago, Kadeton said:

Perhaps I lack imagination. I don't think the sentence is particularly ambiguous, and I think the explanation in FAQ #88 makes it as clear as it needs to be. You've asserted the opposite, but you haven't actually put forward any evidence to support that. Would you care to?

Either of the algorithms I presented results in the same outcome as that FAQ answer. I don't see how that is supposed to prove anything other than the fact that rules are ambiguous.

9 minutes ago, Kadeton said:

I've explained my reasoning in detail. If you need clarification on any part of it, I'm happy to answer questions. If you've got counter-arguments, I'm happy to hear them and discuss them. But if all you've got is "Nuh uh!" then I'm not really interested in engaging further, and to be honest I'm not sure why you are either.

Existence of two possible interpretations is enough to prove that the rules aren't completely clear. It's you who needs to prove that one of them contradicts the rules if you want to claim you are right.

The only reason I'm interested in this discussion, is that I loathe unnecessary ambiguity and would like to see it cleared away by a FAQ answer.