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 :).

[Adran]

I would argue that you don't backtrack and have to check ownership. Whilst Immunity would remove existing conditions if they were subject to its immunity, once the condition is placed on a model, it has not built in reason to track the placing model, and as such the burning on the model is no longer a condition caused by an enemy model or caused by a friendly model, but just a condition. 

[santaclaws01]

I'm leaning towards the condition isn't removed. Conditions don't track ownership, specifically for things like Burning and Poison, so after the condition is applied it is beyond the point of checking if an enemy is applying the condition or not.

[dancater]

Well here is a nightmare question and that is a fact.

I think that generally you simply have, have, have to minimize tracking and paperwork.  So I'd be inclined to simply say the condition exists and is not removed, that means no arguments or issues backtracking through previous events.

Perfectly understand the argument (which is 100% valid and makes sense) to remove Paralyze but as pointed out by WWHSD this then collides with stacking conditions which may have multiple sources friendly and enemy.  So...

• You can leave the condition active, no major paperwork needed and the onus is on the player to maintain the Blood Ward safety bubble.  I don't like this, it goes against upgrade wording and also the spirit of the upgrade.  However, I think that given the need to minimize potential discussion/conflict at the table on where and when a condition came from, especially with stacking conditions, this is probably the safest and least problematic way to deal with a hopefully rare occurrence.
• Ends the condition based on the last application (WWSHD [C] option) so if the last application came from an enemy condition is over, if not it persists.  Might make the most sense from a upgrade wording point of view and in minimizing paperwork, but still could be problematic.  This is my second option for stand in rule.
• Auto end "hostile" (meaning damaging or AP reduction etc) conditions regardless of source (so Carlos loses all his Burning, no matter what).  Minimal paperwork but expressly goes against upgrade wording (enemy and not hostile) and still leaves open arguments over what exactly constitutes 'hostile' particularly in certain schemes/strats.
• Ends the 'part' of any condition caused by an enemy, so Carlo's friendly Burning persists but the enemy Burning drops.  A paperwork nightmare and invitation for table arguments.
• You could also separate Blood Ward so it ends no stacking negative/enemy conditions (like Paralyze and Slow) but does not impact stackable conditions (like Burning and Poison).  Easy on the paperwork but makes absolutely no sense in rules and upgrade wording terms.

I think this is probably rare enough that it does not demand an FAQ but I still think its the type of thorny rules wording issue that does require official clarification at some point. 

 

[WWHSD]

4 minutes ago, Philosfr said:

I think the difference is how we see the "immunity". If a model becomes immune to burning, the rules tell us to drop burning. But this ability isn't making a model immune to burning. It's making a model immune to conditions caused by enemy models. A model isn't immune to burning if it's from a friendly, just if it's from an enemy. 

 

This is the key distinction I think. I think it is only immune to an enemy applying conditions, which is different from immunity to a condition. Since it's a condition (not enemy or friendly) that is affecting the model, it wouldn't drop off when it became immune to the enemy applying conditions.

 

Granted, that may not be what is intended, but I think the scheme/strategy scoring is a more solid ruling than the "immunity causes conditions to fall off" ruling in this case, hence still believe it wouldn't fall off.

I'm sorry but that just doesn't make much sense to me. If the condition was caused by an enemy when it was applied I don't see how it stops being caused by an enemy after it was applied. I don''t get what would make this change. 

How to handle how a stacking condition has been caused by both an friend and an enemy is a separate issue than the original question. With a simple condition that does not stack, there is never any question about whether it was caused by a friend or an enemy since any subsequent application of the condition would fail. If we need to figure out what to do with stacking conditions, we can look to how to handle duration as a precedent. That seems just as valid as trying to use scheme and strategy scoring rules as a precedent for whether or not conditions have causes while still agreeing with the rules that actually exist.

 

 

[WWHSD]

On 12/11/2017 at 6:08 AM, santaclaws01 said:

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

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. 

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.

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. Malifuax is full of examples of information that players need to track even though they are never explicitly told to do so.  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. The game never explicitly tells us to track this information but we do it because we know it's significant information that may be relevant later.  

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.   

 

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.

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

My preference is for #2 since that's consistent with how duration on conditions are handled and it seems like the easiest one for me to track mentally and work back to with my opponent if needed. Do the rules say that's the way to handle it? Nope, but I haven't claimed to know the right way to handle that. 

[Philosfr]

I wasn't sure, but thinking about burning makes me think that you would NOT lose any conditions that were on you already

That's because of scoring schemes and such. If a Frame for Murder target dies from burning, it doesn't count as the enemy killing them, so the condition wasn't "owned" by the enemy. Based on that, I would say you're only immune to enemy models applying conditions, not immune to conditions themselves.

So I'd say D) Burning +4, because the conditions were on the target before it was in the aura

[WWHSD]

43 minutes ago, Philosfr said:

I wasn't sure, but thinking about burning makes me think that you would NOT lose any conditions that were on you already

That's because of scoring schemes and such. If a Frame for Murder target dies from burning, it doesn't count as the enemy killing them, so the condition wasn't "owned" by the enemy. Based on that, I would say you're only immune to enemy models applying conditions, not immune to conditions themselves.

So I'd say D) Burning +4, because the conditions were on the target before it was in the aura

The wording isn't saying anything about ownership of the condition. It is looking for what caused the condition.
 

Per the rules you do remove existing conditions when you gain an immunity.

Big Core, pg. 39:
"If a model gains immunity to a Condition while it
has the Condition, it immediately removes the Condition."

 

[Philosfr]

7 minutes ago, WWHSD said:

The wording isn't saying anything about ownership of the condition. It is looking for what caused the condition.
 

Per the rules you do remove existing conditions when you gain an immunity.

Big Core, pg. 39:
"If a model gains immunity to a Condition while it
has the Condition, it immediately removes the Condition."

 

I'd agree if they were gaining immunity to a condition. But the wording makes it seem like they're gaining immunity from an enemy applying conditions. That's a slight difference, and enough to make me think they wouldn't lose conditions they already had

[WWHSD]

7 hours ago, Adran said:

I would argue that you don't backtrack and have to check ownership. Whilst Immunity would remove existing conditions if they were subject to its immunity, once the condition is placed on a model, it has not built in reason to track the placing model, and as such the burning on the model is no longer a condition caused by an enemy model or caused by a friendly model, but just a condition. 

If a model with Warding Runes is paralyzed and then the Blood Mage comes back into range or LoS you would leave the model paralyzed?

More complicated stacking conditions aside, the rules are pretty clear in stating that conditions are removed when a model that was not immune to them gains immunity. Warding Runes is giving you a reason to track the cause of a condition as it considers the source of a condition to be relevant. The entire argument against immunity working for Warding Runes like it does for everything else seems to boil down to "a model that does from burning doesn't count as being killed by the model that inflicted burning" and "it's inconvenient to track the source of a condition". 

Without any additional book keeping it's usually clear whether you or your opponent inflicted a condition. The cases where a condition is going to be confusing to track are the exception. Carlos playing against enemies with burning or a Marcus Venomancy crew playing against enemies with poison that tracking which crew caused the condition becomes an issue.    

If it wasn't the intention to have Warding Runes work like other immunities why not just word it more like Nihilism and use something like  "Conditions caused by enemy models may not be placed on this model". 

[santaclaws01]

3 hours ago, WWHSD said:

If a model with Warding Runes is paralyzed and then the Blood Mage comes back into range or LoS you would leave the model paralyzed?

More complicated stacking conditions aside, the rules are pretty clear in stating that conditions are removed when a model that was not immune to them gains immunity. Warding Runes is giving you a reason to track the cause of a condition as it considers the source of a condition to be relevant. The entire argument against immunity working for Warding Runes like it does for everything else seems to boil down to "a model that does from burning doesn't count as being killed by the model that inflicted burning" and "it's inconvenient to track the source of a condition". 

Without any additional book keeping it's usually clear whether you or your opponent inflicted a condition. The cases where a condition is going to be confusing to track are the exception. Carlos playing against enemies with burning or a Marcus Venomancy crew playing against enemies with poison that tracking which crew caused the condition becomes an issue.    

If it wasn't the intention to have Warding Runes work like other immunities why not just word it more like Nihilism and use something like  "Conditions caused by enemy models may not be placed on this model". 

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.

[Adran]

On 08/12/2017 at 5:34 PM, WWHSD said:

If a model with Warding Runes is paralyzed and then the Blood Mage comes back into range or LoS you would leave the model paralyzed?

More complicated stacking conditions aside, the rules are pretty clear in stating that conditions are removed when a model that was not immune to them gains immunity. Warding Runes is giving you a reason to track the cause of a condition as it considers the source of a condition to be relevant. The entire argument against immunity working for Warding Runes like it does for everything else seems to boil down to "a model that does from burning doesn't count as being killed by the model that inflicted burning" and "it's inconvenient to track the source of a condition". 

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.

And Partially because if you look at the big picture, the rule would need to be consistent with those complicated situations, and my view of the rules would be easily understood and clear to all. 

[Adran]

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

Sure, there is no where in the rules that says conditions on a model no longer remember who caused them. But there are rules for how conditions combine, and they don't have any rules about merging ownership, which at least supports the view that conditions don't retain that knowledge. 

would you want the model with immunity to damage caused by to Heal up the damage it suffered for a while it wasn't immune? I don't think we are supposed to track at that detail. 

[WWHSD]

1 hour ago, Adran said:

Sure, there is no where in the rules that says conditions on a model no longer remember who caused them. But there are rules for how conditions combine, and they don't have any rules about merging ownership, which at least supports the view that conditions don't retain that knowledge. 

would you want the model with immunity to damage caused by to Heal up the damage it suffered for a while it wasn't immune? I don't think we are supposed to track at that detail. 

There’s no reason to think that immunity to  damage would work that way. The rule that causes conditions to be removed when a model gains immunity only deals with conditions, not anything else that a model might be immune to.

 

[Philosfr]

7 hours ago, WWHSD said:

There’s no reason to think that immunity to  damage would work that way. The rule that causes conditions to be removed when a model gains immunity only deals with conditions, not anything else that a model might be immune to.

 

I think the difference is how we see the "immunity". If a model becomes immune to burning, the rules tell us to drop burning. But this ability isn't making a model immune to burning. It's making a model immune to conditions caused by enemy models. A model isn't immune to burning if it's from a friendly, just if it's from an enemy. 

 

This is the key distinction I think. I think it is only immune to an enemy applying conditions, which is different from immunity to a condition. Since it's a condition (not enemy or friendly) that is affecting the model, it wouldn't drop off when it became immune to the enemy applying conditions.

 

Granted, that may not be what is intended, but I think the scheme/strategy scoring is a more solid ruling than the "immunity causes conditions to fall off" ruling in this case, hence still believe it wouldn't fall off.

[WWHSD]

1 hour ago, santaclaws01 said:

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.

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. 

We have an ability that says that a particular piece of information about the game state is important to know. It's a piece of information that we obviously have at some point in time if the ability ever actually does anything. Why would the cause of a condition change or stop to be relevant once the condition has been applied?  There's no rule that tells us to clear that peice of information about the game states.

 

1 hour ago, santaclaws01 said:

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

Again, the rules don't tell us to track a lot of things about the game state that actually do need to be tracked. Just because the rules don't explicitly tell you to track information doesn't make the information unavailable. 

 

1 hour ago, santaclaws01 said:

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.

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

 

1 hour ago, santaclaws01 said:

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

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. 

 

1 hour ago, santaclaws01 said:

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.

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.

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.

 

1 hour ago, santaclaws01 said:

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.

That little number allows the condition to be applied from more than one source. Not having the little number means that there can never be more than a single source for the condition. 



 

[WWHSD]

5 hours ago, santaclaws01 said:

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.

When it comes to deciding what gets tracked on the fly I don't see a difference between a condition or marker that says that it goes away when the model that placed it leaves play and an ability that says that it cares about the source of a conditions that go on a model. 

 

5 hours ago, santaclaws01 said:

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.

Is that stated somewhere or is that just an opinion?

 

5 hours ago, santaclaws01 said:

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.

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.

 

 

5 hours ago, santaclaws01 said:

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.

Off the top of my head, Rasputina's ability to give a model with the Paralyzed condition Frozen Heart or a model with Immunity to Burning getting out of range of Eternal Flame are both examples of where models would get a condition removed by gaining Immunity to the condition.   

 

 

It seems that the entire argument against Warding Runes removing conditions when the Blood Mage comes back into range or line of sight is centered around this FAQ entry:

"2) 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." 

Where is the link between kill credit and forgetting about the source of a condition. That's what I've been asking for. Knocking a model off of terrain and killing them also doesn't give any credit and that's pretty straight forward. 

[SunTsu]

On 1/1/2018 at 8:33 PM, Adran said:

I wasn't impressed by Sun tsu answer because it has faulty reasoning. Applying timing conditions based on models is not limited to just the models causing they can also be based on other models.

And so? What does it mean? If a timing clause calls for specific model(s) or situation(s), it's really obvious you need to track them... It's a fact. On this there isn't any margin for debating, I guess. The fact is that you have to track every specific clause a condition states in order to handle that condition properly.

On 1/1/2018 at 8:33 PM, Adran said:

Regardless we have 2 choices, one which says the rules don't ask us to track it,

Except the fact that you NEED to track it in order to let those conditions/effects/situations work properly...

For exemple in Ours strategy, you need to track which are summoned models, or the strategy simply don't work as intended. No rules explicitly says you to track it. So, how do you play Ours???

On 1/1/2018 at 8:33 PM, Adran said:

The second leads to lots of extra questions to answer, not limited to what to do about stacking, but also I could come up with some when models change from friendly to enemy and so forth.

This is why I wrote it's a black hole. However, by rules models never flip from one side to the other, passign from enemy to friendly. There are some few actions (Hungering Darkness and Sybelle comes to my mind), stating that "target consider this model friendly for the duration of the action" (quoted from HD, but Sybelle have a very similar wording). "Counts" a model as friendy, it's not the same to becoming friendly/enemy or changing its own crew.

 

On 1/1/2018 at 9:07 AM, Rillan said:

U get conditions in sequence. So if u get 2+2 at the end of turn u drop 1 point from last coming condition. In this case the enemy ones, so when mage comes closer it removes the last 1 point that came from enemy model. If people dont want to track things its not game problem.

No, This is exactly the black hole I was speaking. As @santaclaws01 correctly wrote, rules explicitly says a stackable condition became a single one when the two merges. Now we don't have any hard-ruled-tool to know how to handle in cases like this, atm.

If I would be calle to a table as a judge to solve this, I think I would reason in plain english and common sense: warding runes says "enemy conditions". So a condition need to be clearly identified as "enemy". Non stackable condition are always trackable. For stackable ones, if in a game it's obvious that condition came from the enemy, then I would rule warding runes works after applying (let's say blighted condition in a game guild vs outcast, or brilliance in a neverborn vs guild one). In those case where there are effects not belonging to a single crew that can apply a specific stackable condition (burning in Sonnia vs Kaeris, or poison in McMourning vs Marcus), I would rule that condition cannot be consider enemy or friendly.

However, I stronglysuggest to wyrd to proceed to an errata to Warding Runes, using a less confusing wording in order to solve the problem. As rules are written, however never said explicitly, the perceived intention is that conditions should never be considered enemy/friendly by itself, but just a "neutral" status on a model. As written Warding Runes broke this paradigma.

[Ludvig]

If you gain immunity to something you have you remove it. Can't remember the wordih but if it grants true immunityyou can dtop the condiion, if it only says ypu can'tgai cpnditions it is obvipusly too late.

[WWHSD]

41 minutes ago, Ludvig said:

If you gain immunity to something you have you remove it. Can't remember the wordih but if it grants true immunityyou can dtop the condiion, if it only says ypu can'tgai cpnditions it is obvipusly too late.

“This model is immune to conditions caused by enemy models and damage from  effects.”

Conditions may not have an alignment but they the do have a cause. With something like Paralyze it’s clear whether it was an Enemy or Friendly model that caused it. I’m not too sure how you’d treat a condition that stacks, like Burning”.

Carlos has Warding runes and self inflicted Burning +2. He gets hit with Burning +2 from an enemy model. If the Blood Mage comes into range and LoS of Carlos what does Carlos end up with:

A) Burning +4. The condition was not initially inflicted by an enemy so the immunity doesn’t kick in.

B ) Burning +2. The Burning +2 from the enemy is removed by the immunity, the self-inflicted burning remains.

C) The burning condition is removed. Because the last model to inflict the condition was an enemy the condition counts as being caused by an enemy model.

 

I’m leaning towards C because it is the easiest to track and because it is consistent with the rules for handling the same condition having different durations (the most recent applicationof the condition is what counts).

[Ludvig]

Man, that's the worst possible wording!  

It's not clear how closely you backtrack the source of conditions already applied and the possibility of conditions from both players stacking makes it a really bad case.

[WWHSD]

9 minutes ago, santaclaws01 said:

I'm leaning towards the condition isn't removed. Conditions don't track ownership, specifically for things like Burning and Poison, so after the condition is applied it is beyond the point of checking if an enemy is applying the condition or not.

But it's not ownership. It's asking what the cause of the condition was. 

[Philosfr]

25 minutes ago, WWHSD said:

But it's not ownership. It's asking what the cause of the condition was. 

But that's not a tracked item in Malifaux. For example, let's say instead of burning, we're talking poison. I give my model 2 poison, then my opponent gives my model 2 poison. End of the turn happens, I take 1 damage and my poison condition drops to 3. Now I enter the immunity aura. Do I drop 1 poison or 2 poison under your scenario? It gets messy.

On the other hand, Malifaux already does have a way of handling the "owner" of conditions, such as for scoring schemes. And that's that the condition doesn't belong to either side. So while it's not a great point, it's at least something on the side of "no conditions drop off".

[WWHSD]

1 minute ago, Philosfr said:

But that's not a tracked item in Malifaux. For example, let's say instead of burning, we're talking poison. I give my model 2 poison, then my opponent gives my model 2 poison. End of the turn happens, I take 1 damage and my poison condition drops to 3. Now I enter the immunity aura. Do I drop 1 poison or 2 poison under your scenario? It gets messy.

On the other hand, Malifaux already does have a way of handling the "owner" of conditions, such as for scoring schemes. And that's that the condition doesn't belong to either side. So while it's not a great point, it's at least something on the side of "no conditions drop off".

I don't see any reason that Warding Runes should be an exception to the rule that we do have about what happens when immunity is gained when you have a condition. It's the stacking of conditions that makes it complicated. The rules don't seem to tell us how to deal with that.

Again, we aren't looking for the owner of a condition, we are being told to look at the cause of the condition. 

[Angelshard]

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

I'd say the condition is removed as the model becomes immune and an immune model can't have the condition.

[Lokibri]

53 minutes ago, Philosfr said:

But that's not a tracked item in Malifaux. For example, let's say instead of burning, we're talking poison. I give my model 2 poison, then my opponent gives my model 2 poison. End of the turn happens, I take 1 damage and my poison condition drops to 3. Now I enter the immunity aura. Do I drop 1 poison or 2 poison under your scenario? It gets messy.

On the other hand, Malifaux already does have a way of handling the "owner" of conditions, such as for scoring schemes. And that's that the condition doesn't belong to either side. So while it's not a great point, it's at least something on the side of "no conditions drop off".

I did think that way at first also, but then WWHSD referred to the "timestamp" so, in this case the condition applied last ticks down first.

However, it is said, that conditions just don`t count for schemes. They can be backtracked to the model that caused it however. They just don`t count for schemes. That`s all.

 

33 minutes ago, Angelshard said:

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

I'd say the condition is removed as the model becomes immune and an immune model can't have the condition.

This is the reason i think condition are tracked in a specific way sometimes and let me lean towards removing the paralyze.

 

I would like to thank you all for the discussion. I think there is still a gap to be answered in a FAQ. Thanks guys

See you in the Bayou!