Warding Runes and pre-existing conditions with Blood Ward

[Lokibri]

Hello everyone,

there was a question regarding Warding Runes and a condition received while the model was not in range of the blood ward aura.

Example: A model with Warding Runes receives paralyze while outside of the Blood Ward. Later on (before the paralyzed model activates) the Ox-Mages comes in range again.

The question now is: What happens?

I think there are two outcomes possible.

The Blood Ward says: This model is immune to conditions from enemies.

A ) The model still has the condition, but is immune to it and therefore removed.

B ) The condition still remains, but per se has no allignment if enemy or friendly. Therefore the model stays paralyzed.

 

I know this topic came up two times before, but there was no clear ruling and i would highly appreciate if we could clear it out.

Thanks mates!

See you in the Bayou :).

[joediamond]

I would argue that you keep any conditions applied while not under the effects of Blood Ward, for reasons people already stated above.

What happens with Stackable Conditions in these scenarios where "ownership" is a thing?  Does "ownership" stay split, as some people have already suggested, or does it defer to the model that applied the latest instance of this condition, similar to how duration works?  What about conditions that can be lowered by models?  Does my Burning +2 model get to choose to remove "my" Burning +1 and leave "your" Burning +1 when it takes the Interact action, or only the most recent application, and why?

20 hours ago, Angelshard said:

Some conditions do track ownership. Primordial magic nullify, for example, specifies "until this model is removed or killed ".

I think that is just specifying non-standard timing for when the condition ends, since Conditions end at the end of the turn unless otherwise specified.  I mean, Forgotten Marshal can apply a condition to an enemy which remains until the start of the target's next activation.  If condition timing tied to a model implies ownership, as you suggest, does this mean the target is the "owner" of the condition, even though the Marshall applied it?  Would that mean it gets around Blood Ward, since the target model (i.e. a friendly model) "owns" the condition?  What about timings that specify multiple models, like the Spotted condition from the Tail 'Em scheme?  The Spotted condition specifies the targeted model and enemy models in it's removal timing.  Who gets "ownership" in that instance?  

45 minutes ago, WWHSD said:

The entire argument against immunity working for Warding Runes like it does for everything else

The trouble I see is that the immunity from Warding Runes does not work like other forms of immunity (although feel free to point one out, if there is one I'm not thinking of).  Even similar enemy-only anti-condition mechanics like Guild's Numb to the World upgrade are worded differently.  For example, Frozen Heart models are immune to Paralyzed.  They don't care where it comes from.  It is unconditional immunity.  Warding Runes is specific in that it has an criteria that cares how the Condition is applied.  It is conditional immunity (pun intended).  

Regardless, I would love an FAQ to clarify this, one way or the other.  I tend play with Warding Runes a lot, so when I am trying to win with my Arcanists, I want to make sure me and my gaming group are on the same...page. 

[Angelshard]

You're right that ownership isn't a good word. Origin is better. It still leaves the problem of some conditions requiring you to track the source though.

[solkan]

55 minutes ago, Angelshard said:

You're right that ownership isn't a good word. Origin is better. It still leaves the problem of some conditions requiring you to track the source though.

The fact that the duration of an effect may be tied to a model in an arbitrarily complex manner doesn't have anything to do with whether the source of a condition is tracked.

For instance, Model X can apply a condition to Model Y that lasts until Model Z activates (or dies, or moves, or whatever).  That doesn't tie the Condition to Model X.

[WWHSD]

11 minutes ago, santaclaws01 said:

That's the thing, Blood ward isn't standard immunity. And immunity means it can be worked around. If a carrion effigy is around for example the model would no longer be immune to poison being applied by an enemy model. And the fact remains that the only time the rules care about what model is applying a condition is when the condition is applied.

I never implied that an ability that ignores or removes immunity (like the Carrion Effigy has) shouldn't be able to ignore or remove immunity. My contention is that in the absence of a more specific rule or ability that overrides the general rules on immunity there's no reason not to follow them.

People in this thread keep asserting that once a condition is applied the source no longer matters. I have yet to see anyone support that with rules. We have an upgrade that makes the source of a condition a piece of relevant information when it normally is not. There's no rule that contradicts that.

We routinely track who buried a model and with which ability but as far as I know the rules never tell us to track that information. It's the upgrades themselves that let us know that this is information that needs to be tracked.

[santaclaws01]

47 minutes ago, WWHSD said:

I never implied that an ability that ignores or removes immunity (like the Carrion Effigy has) shouldn't be able to ignore or remove immunity. My contention is that in the absence of a more specific rule or ability that overrides the general rules on immunity there's no reason not to follow them.

People in this thread keep asserting that once a condition is applied the source no longer matters. I have yet to see anyone support that with rules. We have an upgrade that makes the source of a condition a piece of relevant information when it normally is not. There's no rule that contradicts that.

We routinely track who buried a model and with which ability but as far as I know the rules never tell us to track that information. It's the upgrades themselves that let us know that this is information that needs to be tracked.

Nothing in the rules state that the source of a condition matters outside of timing. The rules for burying however state that the specifics of each burry are determined by the action or ability that buried a model, and that the owner of the bury affect controls the unbury as well, so yes, the rules do tell us to track that information as it is explicitly stated as relevant. No such mentions exist for conditions, and without any rules saying it matters, it doesn't, especially when there is an implicit confirmation in that kills by conditions don't count for anyone, meaning the origin of the condition doesn't matter after it is placed.

 

I brought up the Carrion effigy immunity removal as a potential reason why they want it to be immunity instead of ignore, so that there is counterplay.

[Ludvig]

There are a lot of things you are required to track who applied, those things tell you to track that and conditions aren't one of them. You don't track stuff the game doesn't explicitly state that you track I think. For you to do something the game basically needs to give you express condition, otherwise I could do all sorts of stuff because the game didn't tell me I couldn't do it. Doesn't say I'm not allowed to randomly mark wounds down on both mine and your models but the game only mentions marking them when you actually suffer them so we don't go around doing it at other times.

[WWHSD]

28 minutes ago, Ludvig said:

There are a lot of things you are required to track who applied, those things tell you to track that and conditions aren't one of them. You don't track stuff the game doesn't explicitly state that you track I think. For you to do something the game basically needs to give you express condition, otherwise I could do all sorts of stuff because the game didn't tell me I couldn't do it. Doesn't say I'm not allowed to randomly mark wounds down on both mine and your models but the game only mentions marking them when you actually suffer them so we don't go around doing it at other times.

Warding Runes says that the source of the condition matters. How is that not the game instructing you to track something?

Von Schill's new upgrade allows friendly models with Oathkeeper to get plus flips in duels against models that Von Schill has damaged this turn. Neither the rules or the upgrade itself explicitly instructs you to track which models Von Schill has damaged. The game only asks you to track the quantity of damage a model has taken, not the source of that damage. I think I'd be ridiculed if I insisted that this ability doesn't actually do anything because in order for it to work we'd need to track something that the game doesn't tells us to track. 

[dancater]

4 minutes ago, WWHSD said:

Warding Runes says that the source of the condition matters. How is that not the game instructing you to track something?

Tracking who placed the condition short term, "this was from that attack that just happened" is different from tracking over multiple events and activation's.  So you could end up with several Poison placed on you or Burning from different sources over a single turn or multiple turns.  I'll admit it is rare but it could happen and I foresee a couple of issues:

• Simply because its such a corner case one or both players will forget to track where stackable condition-x originated from, it simply won't enter there minds particularly in a more pressure tournament event when it is likely to be more important and potentially controversial.  At best it adds more paperwork at worst it leads to the next problem.
• If both players have not tracked the stackable-x condition then it may result in arguments as to which and what was stacked by who and when.  Depending on the game this could be a huge swing in a game.

Honestly this really, really is such a corner case.  In a non-tournament game its simple to house rule and happens rarely.  In a tournament game it requires Warding Runes and the character receiving the condition to be outside the Blood Ward aura and then inside the Blood Ward aura while the condition is active.  I think it will be relatively rare.  If pushj comes to shove and you're entering an event running a Warding Runes crew you go to the TO before game start and have them clarify with you and your opponent what the strat will be if it comes up.

But in the end I think it does need a FAQ to clarify how Wyrd thinks it should play out.   

[WWHSD]

7 minutes ago, dancater said:

Tracking who placed the condition short term, "this was from that attack that just happened" is different from tracking over multiple events and activation's.  So you could end up with several Poison placed on you or Burning from different sources over a single turn or multiple turns.  I'll admit it is rare but it could happen and I foresee a couple of issues:

• Simply because its such a corner case one or both players will forget to track where stackable condition-x originated from, it simply won't enter there minds particularly in a more pressure tournament event when it is likely to be more important and potentially controversial.  At best it adds more paperwork at worst it leads to the next problem.
• If both players have not tracked the stackable-x condition then it may result in arguments as to which and what was stacked by who and when.  Depending on the game this could be a huge swing in a game.

Honestly this really, really is such a corner case.  In a non-tournament game its simple to house rule and happens rarely.  In a tournament game it requires Warding Runes and the character receiving the condition to be outside the Blood Ward aura and then inside the Blood Ward aura while the condition is active.  I think it will be relatively rare.  If pushj comes to shove and you're entering an event running a Warding Runes crew you go to the TO before game start and have them clarify with you and your opponent what the strat will be if it comes up.

But in the end I think it does need a FAQ to clarify how Wyrd thinks it should play out.   

I agree that the more complex scenarios make this a mess. I think that the most straight forward application of the written rules should win out over what makes the complicated stuff easier to deal with though. Someone wanting to figure out if Carlos get's unparalyzed when the Blood Mage gets back in range is going to crack open the rule book, find a passage that applies and do what it says. They aren't going to go check the FAQ because they found an answer that I imaging that most people would find sufficient in the rules.

It's the folks with the complex situations that aren't easily answered by looking at the rules (and that probably require some understanding of developer intent) that are going to go look in the FAQ. 

[santaclaws01]

58 minutes ago, WWHSD said:

Warding Runes says that the source of the condition matters. How is that not the game instructing you to track something?

Von Schill's new upgrade allows friendly models with Oathkeeper to get plus flips in duels against models that Von Schill has damaged this turn. Neither the rules or the upgrade itself explicitly instructs you to track which models Von Schill has damaged. The game only asks you to track the quantity of damage a model has taken, not the source of that damage. I think I'd be ridiculed if I insisted that this ability doesn't actually do anything because in order for it to work we'd need to track something that the game doesn't tells us to track. 

Except Oath of the Freikorps makes Von Schiller give the Priority Target condition after damaging an enemy model, so swing and a miss.

[WWHSD]

43 minutes ago, santaclaws01 said:

Except Oath of the Freikorps makes Von Schiller give the Priority Target condition after damaging an enemy model, so swing and a miss.

I had that backwards didn't I. It's a bad example but my point still stands that the Warding Runes makes the source of a condition significant. It doesn't matter that the general rules don't explicitly tell you to track that piece of information. Once an upgrade makes it important it needs to be tracked.

[WWHSD]

3 hours ago, santaclaws01 said:

Nothing in the rules state that the source of a condition matters outside of timing. The rules for burying however state that the specifics of each burry are determined by the action or ability that buried a model, and that the owner of the bury affect controls the unbury as well, so yes, the rules do tell us to track that information as it is explicitly stated as relevant. No such mentions exist for conditions, and without any rules saying it matters, it doesn't, especially when there is an implicit confirmation in that kills by conditions don't count for anyone, meaning the origin of the condition doesn't matter after it is placed.

 

I brought up the Carrion effigy immunity removal as a potential reason why they want it to be immunity instead of ignore, so that there is counterplay.

 

Nothing in this rule block explicitly instructs you to track the cause of being buried. It's something that a reasonable reader would assume that needs to be done when reading the the bit on Unburying. I don't see how that is any different than reading Blood Ward and deciding that you should probably track the source of a condition.

M2E Big Core, pg 47:

"Buried
Some Actions will bury a model. When a model is
buried it is removed from play (usually set on its stat
card as a reminder). The model is not counted as killed
or sacrificed when it is buried.
Buried models cannot Activate. In addition, buried
models are never considered to be in LoS or within
range of effects. These models do not count as "in play"
for the purposes of other rules that reference whether or
not a model is in play.
Buried models still process Conditions and other
effects that happen at the end of the Turn (such as
the Burning or Poison Conditions).
If a model becomes buried during its Activation, end
its Activation (it loses all AP and moves to the End
Activation Step).
Unbury
Some effects will unbury a model. This is usually
described in the Action that initially buried the model.
When this happens, place the model back into play as
described in the unburying effect.
When unburying models, if the models do not
physically fit in the specified location, they are placed
in their controller’s Deployment Zone by the player
who controls them. If models from multiple players
were all unburied at the same time, the First Player
(see pg. 35) places her models first."

[santaclaws01]

3 minutes ago, WWHSD said:

 

Nothing in this rule block explicitly instructs you to track the cause of being buried. It's something that a reasonable reader would assume that needs to be done when reading the the bit on Unburying. I don't see how that is any different than reading Blood Ward and deciding that you should probably track the source of a condition.

M2E Big Core, pg 47:

"Buried
Some Actions will bury a model. When a model is
buried it is removed from play (usually set on its stat
card as a reminder). The model is not counted as killed
or sacrificed when it is buried.
Buried models cannot Activate. In addition, buried
models are never considered to be in LoS or within
range of effects. These models do not count as "in play"
for the purposes of other rules that reference whether or
not a model is in play.
Buried models still process Conditions and other
effects that happen at the end of the Turn (such as
the Burning or Poison Conditions).
If a model becomes buried during its Activation, end
its Activation (it loses all AP and moves to the End
Activation Step).
Unbury
Some effects will unbury a model. This is usually
described in the Action that initially buried the model.
When this happens, place the model back into play as
described in the unburying effect.
When unburying models, if the models do not
physically fit in the specified location, they are placed
in their controller’s Deployment Zone by the player
who controls them. If models from multiple players
were all unburied at the same time, the First Player
(see pg. 35) places her models first."

Emphasis mine. Although I will concede that it's not explicit. This tells you that you need to track bury effects for the purpose of burying a model. If a bury effect doesn't detail how to unbury a model, then it doesn't need to be tracked.

[Lokibri]

3 hours ago, WWHSD said:

Warding Runes says that the source of the condition matters. How is that not the game instructing you to track something?

Von Schill's new upgrade allows friendly models with Oathkeeper to get plus flips in duels against models that Von Schill has damaged this turn. Neither the rules or the upgrade itself explicitly instructs you to track which models Von Schill has damaged. The game only asks you to track the quantity of damage a model has taken, not the source of that damage. I think I'd be ridiculed if I insisted that this ability doesn't actually do anything because in order for it to work we'd need to track something that the game doesn't tells us to track. 

I think you have a very valid point here ! And in my opinion this whole confusion begins with the fact, that "conditions" can kill models, but state, that "no crew is determined for having made that kill". I think that is the part, where people start thinking about the situation and treat them as "neutral" conditions. Just as condition with no allignment or belonging. BUt as a matter of fact, we could of course backtrack them and find the source, they just don`t score for killy schemes and thats it. Maybe it should be clarified in the general rules, that the origin may be from Player B on Player A's model, but it just doesn`t count e.g. for dig their graves (because no immediate attack was involved, that is required by some schemes).

Thank you all guys for this discussion :).

 

See you in the Bayou!

[Ludvig]

+1 to Adran's reasoning.

[WWHSD]

2 hours ago, Adran said:

Yes I would leave it paralysed.

Partially because once a model has the condition on it, it is no longer a condition from an enemy,. Once the attack is finished the condition is just a condition.

People in this thread keep making this assertion but no one has pointed to rules that state this.  The closest thing anyone has come up with is that a model that dies from burning or poison doesn’t count as being killed by either crew. That’s not the same thing.

[santaclaws01]

57 minutes ago, WWHSD said:

People in this thread keep making this assertion but no one has pointed to rules that state this.  The closest thing anyone has come up with is that a model that dies from burning or poison doesn’t count as being killed by either crew. That’s not the same thing.

And you haven't supported the opposite position, so stop acting like this gives you any credence.

[SunTsu]

On 11/12/2017 at 10:06 PM, Philosfr said:

I think it is only immune to an enemy applying conditions

Sorry, but "I think" it's not enough...

When at first I read the OP's question, I thought immediately "Ok, easy answer: you cannot drop the condition". But after further reading and thinking about the various exemples around, I changed my mind. It's not an easy answer, it's an impossible one.

The problem here is that we can think all that we want, but we have some bad written rules in this particular case. First the "immunity" is a precisely defined rule in the rulebook, that include dropping conditions already on the models. About tracking conditions, we had some exemples of conditions that would fall after being applied (another exemple I can make is Amina Naidu that can make a model peon and insignificant until Amina itself is killed). On the other hand we have that conditions like burning/poison/etc are not referrable to a particular model, so giving the feel that conditions have no memory (but this isn't formalized in any part of the rules).

So now we have a problem...

I don't know exactly which was the intention here. I can guess that using the term "immunity" and not something like "gain", effectively the writer of this rule would mean that it works even after the condition had been applied.

Remain the problem about stackable conditions.

For me, the way more near to RAW to handle this should be, at the moment, let dropping conditions after these had been applied, exept for stackable conditions where the ownership is theorically impossible to track down.

Obviously, it absolutely requires a faq/errata. But I guess it would be not a so easy task.

Remain the black hole of some conditions having memory, while others have not... that's a hole in the base rules that makes things a little incoherent...

[SunTsu]

4 hours ago, WWHSD said:

It seems like there are at least 3 ways to handle stacking conditions.

1. Whoever applied it first caused it.
2. Whoever applied it most recently caused it.
3. Everyone that applied it counts as causing it.

I would add a point:

4. No one counts as causing it.

That is more coherent with the rule saying a model killed by poison/burning is killed by no one. And for this reason my preference goes for it.

[santaclaws01]

7 hours ago, WWHSD said:

How have I not supported my position? The only actual rules that we really have are "If a model gains immunity to a Condition while it has the Condition, it immediately removes the Condition." (pg. 39). My position is that we should do exactly that. I'm not advocating doing something other than what the rules say to do. 

You haven't given a rule book quote that states that you need to track who caused a condition, yet keep placing the burden of needing a rules quote that says it's never tracked on everyone that's disagreeing with you. All I'm doing is holding you to the same standard you're attempting to hold everyone else up to.

 

Quote

In the case of non-stacking conditions we absolutely have a way to know what caused the condition. With stacking conditions we are still going to know what caused the condition the majority of the time. The corner case of both friendly and enemy models applying the same stacking condition is the only time that the cause of the condition is in doubt and the rules don't seem to give any guidance as to how to handle it.

Because there's nothing in the rules about needing to track it period.

 

Quote

I reject the idea that we can't know the cause of a condition because the game doesn't tell is to write that down

Then you're pretty late on that front with the whole conditions can't give kill credit specifically because of stacking conditions muddying the waters.


 

Quote

Malifuax is full of examples of information that players need to track even though they are never explicitly told to do so.

Yes, just implicitly told to do so and not information that already has a precedent set of not tracking it.

 

Quote

For instance,  if Colette Prompts Howard Langston to move and attack and then Cassandra Understudies to prompt him again it is clear that she can't because he has already been the target of Prompt this turn.

I disagree with that, but that's another topic.

 

Quote

The question that started this thread has nothing to do with stacking conditions and seems to have a straight forward answer that can be found in the rules. The onus of providing evidence should be on the crowd that is advocating doing something other than what the rules say to do.   

It has everything to do with stacking conditions because it's a question about conditions. It does not have a straight forward answer that can be found in the rules because literally nothing about it can be found in the rules, and when a person is saying to do something that's not found in the rules the onus is on them to provide back up for their assertion. Sometimes it's as easy as Beacon, where it literally wouldn't work unless which actions were taken by other friendly models is tracked. That's not the case here however, as warding runes still works even it if doesn't remove already present conditions.


 

Quote

When it comes to handling the more complicated case of stacking conditions, I don't have a strong position on how it should be handled because the rules don't tell us how to deal with it. It seems like there are at least 3 ways to handle stacking conditions.

We deal with stacking conditions the exact same way we deal with any other condition. The fact that it has a little number next to it doesn't mean anything except for at least 1 specific case with the Shadow Emissaries Shenlong Conflux, where it explicitly tells us how to deal with stacking vs non-stacking conditions.

[santaclaws01]

2 hours ago, WWHSD said:

There's a ton of things that the rule book doesn't tell you to track that get tracked to make the game playable. If tracked only the items that the rules explicitly call out as needing to be tracked there's a lot that would break. If an ability makes a piece of information about the game state important, that information needs to be tracked. That's not a rule, that's just common sense to make the game work. 

 

There really isn't though. Everything that gets tracked that the rules don't tell you to track is specifically for whatever action or ability it is that requires the tracking. Things like the PM's Nullify even isn't telling you to track anything, it's just setting the end time for the condition in an unusual way, just like Zoraida has a push that sets the distance in an unusual way. What model applied a condition is just never part of the game state after the fact.
 

Quote

Where does "conditions can't give kill credit specifically because of stacking conditions muddying the waters" come from? The bit in the FAQ just says "If a model is killed by a Condition, which Crew counts as having made the kill? No model or Crew counts as having made the kill.". There's no mention of intent or explanation as to why conditions don't give credit for the kill. The intent could just as well have been "we want a way for a crew to be able kill models without it counting for or against them".
 

Your precedent for not tracking the cause of a condition is that models killed by a condition don't count as being killed by either crew. That's not actually a precedent saying not to track the cause of a condition, it just says that no one gets credit for a kill. There are several conditions that require tracking which model caused the condition. 

And kills don't count for conditions precisely because of Burning and Poison, which are stackable conditions that while can be tracked for who applied it when it's just not worth the effort. It's not like Braced Yari is a particularly hard condition to track for who actually made the kill.

 

Quote

The question was about Paralyze. If a model has the Paralyzed condition any  further attempt to apply the Paralyzed condition fails. The rules are clear about that. Since there can only be a single model that caused the Paralyzed condition there is no ambiguity about whether a friendly or enemy model caused the condition. The rules also clearly tell us that when a model that has a condition gains immunity to a condition that the condition is removed. Those two bits of rules are enough to answer the question that was posed. We have a condition, it is obvious that it was caused by an enemy, we gain immunity to it, we remove it. That's a clear and simple application of the rules as written. There's nothing outside of the rules going on there.

 

It doesn't matter that the question was only about Paralyzed. Immunity to conditions works the exact same way for stackable and non-stackable conditions. However Blood Runes affects one it will have to affect the other in the same way. It doesn't matter how obvious it is or not that the condition was applied by an enemy model, again going back to conditions not counting for a kill. It is very obvious what model is really doing the damage for any number of conditions. None of that matters though.

 

Quote

I'd disagree that the immunity in Warding Runes works if we aren't allowed to remember what caused a condition since part of what immunity does is to remove existing conditions. If you consider Warding Runes to work because it's not totally useless if we forget the cause of conditions once applied then I'd argue that Beacon "works" even better if we aren't allowed to track which abilities have been used in a turn.

It does work if the game only checks who is applying a condition at the time of application. It really doesn't matter that part of what immunity does is remove the thing you're immune to once you gain immunity, because most immunities can't even work like that because of what they make you immune to. Quite simply it doesn't make a model immune to conditions, it makes a model immune to enemy models applying conditions to them. Just a nihilism that can be worked around.

[solkan]

 

1 hour ago, WWHSD said:

I agree that immunity to conditions works the same way for stackable and non-stackable conditions. If Burning or Poison was caused by an enemy it would be removed. The question that isn't answered in the rules and that wasn't asked in the original post how to handle the cause for a condition like Burning if it is applied by both friendly and enemy models. Knowing the cause of a condition and giving kill credit to a crew are two separate things. I haven't seen anything that says that the reason that kill credit isn't given for conditions is because we stop knowing the source of a condition once it has been applied.

Please supply any good reason why you would keep track of the source of the Condition and then not bother to use that information to assign credit using that same information.

Otherwise, you seem to be saying "The FAQ says we don't do it for this case, but I want to do it for this other case."

After all, if you're tracking the source of every Condition (including the Conditions that the rules specify have combined into one), why wouldn't you be consistent with that information.

And do note that the rules for Conditions does state that numeric Conditions such as Burning combine together.  So a model with Burning +3 on it that is the result of Burning +1 applied by three different sources has one Condition on it that was equally caused by all three sources and none of them (it's the result of the Condition rules combining three different Conditions in sequence.)

 

 

[Ludvig]

Anyone who goes to a tournament should have the latest faq printed and give it a readthrough a few days in advance, possibly highlighting a few passages they know will be relevant to their models. 

In a beer and pretzels game at the club you don't need to be 100% up to speed and can work something out on the spot.

[WWHSD]

On 12/16/2017 at 11:40 AM, solkan said:

 

Please supply any good reason why you would keep track of the source of the Condition and then not bother to use that information to assign credit using that same information.

Otherwise, you seem to be saying "The FAQ says we don't do it for this case, but I want to do it for this other case."

After all, if you're tracking the source of every Condition (including the Conditions that the rules specify have combined into one), why wouldn't you be consistent with that information.

I don't see the disconnect. The FAQ entry doesn't care what the cause of a condition is, conditions just don't give kill credit. The same is true for falling or hazardous terrain. I might be missing something but I think it's probably safe to say that unless damage (or an effect that kills or sacrifices) comes directly from an ability on a model then credit for a kill is never awarded.

 

 

On 12/16/2017 at 11:40 AM, solkan said:

And do note that the rules for Conditions does state that numeric Conditions such as Burning combine together.  So a model with Burning +3 on it that is the result of Burning +1 applied by three different sources has one Condition on it that was equally caused by all three sources and none of them (it's the result of the Condition rules combining three different Conditions in sequence.)

Having a stacking condition count as being caused by any model that contributed to the stack seems just as valid as any other way to handle it. That was one of the options I listed for ways it could be handled. If that's the one that's best supported by the rules then it makes sense that it's the one that should get used. 

[SunTsu]

The problem here is that Wyrd forgot to define something in the ruleset.

We have Immunity rules, saying that a condition is dropped if a model gains immunity.

Rune Ward gives a model Immunity to conditions caused by enemies. It's not written that the model don't gain a conditions, it's written that it gets "immunity", with all that is ralate in immunity rules.

Wyrd never explicitly defined condition as having no memory.

More. Wyrd wrote some rules with conditions that pretend explicitly players to track which model applied it.

Saying that, when a condition states it's removed when the model applied it goes out of play, it is just a timing clause, it's just a sophistic trick. I mean, it is obviously a timing clause. But that timing clause explicitly prescribe to track to source of the condition.

Example: you have two crews fighting. Both have an Amina Naidu in game, and both these models gave around conditions that make models peon. At a certain point, one of the two model is killed. Do you remove all the conditions in play, or just those applied by the killed model? And, to do this, you don't need to record and track back which was the model that applied each conditions?

 

This can like or dislike, but it's a case of a black hole. About conditions, some ruling let's say that these don't keep memory (killed models by a condition don't count as killed by any crew). Some other ruling says you absolutely need to track it (see my example just before).

So, at the moment isn't really clear how to handle all the possible situations about these. But for sure, reading the RAW, Warding Runes wording it's enough to justify keeping track of conditions that usually players don't need to track. Because it's effectively a game rule. The problem is just about stackable conditions...