Forum adverts like this one are shown to any user who is not logged in. Join us by filling out a tiny 3 field form and you will get your own, free, dakka user account which gives a good range of benefits to you: No adverts like this in the forums anymore. Times and dates in your local timezone. Full tracking of what you have read so you can skip to your first unread post, easily see what has changed since you last logged in, and easily see what is new at a glance. Email notifications for threads you want to watch closely. Being a part of the oldest wargaming community on the net. If you are already a member then feel free to login now.

 DeathReaper wrote:

rigeld2 wrote:
You're told to determine if all models in a unit have the same save and then use that save as the units save.

and lets say those models fail one save, and those models have the Swarms rule.

Has a Swarm suffered an unsaved wound after the failed save? (Hint: Yes it has).

The models don't make the save, the unit does. So no, the models have not.
Unless you'd like to show me where on page 15 under "same save" a model is making the save?
That's ignoring the fact that you continue to misrepresent the Armor Save rules (which require allocation) as being more specific than the Same Save rules.

rigeld2 wrote:

sirlynchmob wrote:

rigeld2 wrote:

sirlynchmob wrote:

rigeld2 wrote:

False. Proof has been provided - you've simply refused to accept it.

You're projecting again.

and Units don't have saves.

You're told to determine if all models in a unit have the same save and then use that save as the units save.
So what save does a unit of Scouts have?

So you still can't prove your point, so you're just going to post random questions now?

How about you answer this question, Other than just saying its wrong. As you can't prove its wrong, I have no reason to follow you on your random tangents.

The point is, which you keep missing, is that you can't claim you have permission to look for models with SR's that apply to saves yet ignore any other SR's those same models have. When are you ever given permission to check for SR's?

I've answered it a few times.
You must determine saves.
To determine saves, you must look for SRs that modify saves.
The Swarm rule does not modify any saves whatsoever.

Now, what save does a unit of Scouts have?

Absolutely 100% false. You're question is as irrelevant as your your claims you've proved or explained anything.

so when do you ever get permission to check for swarm?

When a model suffers an unsaved wound.

My question isn't irrelevant, I'd appreciate an answer. And I've explained/proved my point - if you disagree perhaps you should respond with a counterpoint proving my assertions wrong?

rigeld2 wrote:

 DeathReaper wrote:

rigeld2 wrote:
You're told to determine if all models in a unit have the same save and then use that save as the units save.

and lets say those models fail one save, and those models have the Swarms rule.

Has a Swarm suffered an unsaved wound after the failed save? (Hint: Yes it has).

The models don't make the save, the unit does. So no, the models have not.
Unless you'd like to show me where on page 15 under "same save" a model is making the save?
That's ignoring the fact that you continue to misrepresent the Armor Save rules (which require allocation) as being more specific than the Same Save rules.

They are not more specific as they cover two totally different things, as I have proven a few pages ago.

rigeld2 wrote:
When a model suffers an unsaved wound.

My question isn't irrelevant, I'd appreciate an answer. And I've explained/proved my point - if you disagree perhaps you should respond with a counterpoint proving my assertions wrong?

You're almost right, but its"If a swarm suffers an unsaved wound from a blast, large blast, or template weapon"

Now when do you have unsaved wounds? in the pool, true?

fine your scouts have a 4+.

But I do love how you like asking for citations and counterpoints, yet you almost never provide any. You provide helpful counterpoints like "Absolutely 100% false."

sirlynchmob wrote:

rigeld2 wrote:
When a model suffers an unsaved wound.

My question isn't irrelevant, I'd appreciate an answer. And I've explained/proved my point - if you disagree perhaps you should respond with a counterpoint proving my assertions wrong?

You're almost right, but its"If a swarm suffers an unsaved wound from a blast, large blast, or template weapon"

Now when do you have unsaved wounds? in the pool, true?

The unit has suffered unsaved wounds if the pool is populated. No model has until allocation.
This means that a Swarm has not suffered an unsaved wound from anything, let alone the mentioned weapon types.

fine your scouts have a 4+.

And how did you determine that?

But I do love how you like asking for citations and counterpoints, yet you almost never provide any. You provide helpful counterpoints like "Absolutely 100% false."

I've provided them in the past - page 15 for the same save rules is all I've needed to support my argument. Page 43? (from memory) for Swarm SR. Page 16 for Armor Save rules.
Please don't pretend I haven't cited rules - I have, and this isn't the first time. Also, your sniping at me isn't productive to the conversation.

rigeld2 wrote:

sirlynchmob wrote:

rigeld2 wrote:
When a model suffers an unsaved wound.

My question isn't irrelevant, I'd appreciate an answer. And I've explained/proved my point - if you disagree perhaps you should respond with a counterpoint proving my assertions wrong?

You're almost right, but its"If a swarm suffers an unsaved wound from a blast, large blast, or template weapon"

Now when do you have unsaved wounds? in the pool, true?

The unit has suffered unsaved wounds if the pool is populated.
This means that a Swarm has not suffered an unsaved wound from anything, let alone the mentioned weapon types.

fine your scouts have a 4+.

And how did you determine that?

But I do love how you like asking for citations and counterpoints, yet you almost never provide any. You provide helpful counterpoints like "Absolutely 100% false."

I've provided them in the past - page 15 for the same save rules is all I've needed to support my argument. Page 43? (from memory) for Swarm SR. Page 16 for Armor Save rules.
Please don't pretend I haven't cited rules - I have, and this isn't the first time. Also, your sniping at me isn't productive to the conversation.

so you're the only one allowed to snipe with irrelevant questions? But when I quote you I'm not being productive to the conversation?

because this:
Absolutely 100% false. What save does a unit of Scouts have?
alse. Proof has been provided - you've simply refused to accept it.

is your way of being productive?

and your
"No model has until allocation." is your opinion and in no way supported by rules.
and as we know that makes it:
Absolutely 100% false.

You just live by double standards don't you, and I guessed.

I actually don't.

And how is "No model has until allocation." Not supported by the rules on page 15? Could you explain that?

I apologize if you felt lighted by my statements, that's not my intent. My intent was to say that your statement was false.

the problem is, people are assuming that when you double the wound in the mixed saves process, that the 2nwound is automatically allocated to the model that suffered it at the same time.

RAW is that you allocate wounds one at a time,
one wound is allocated to the swarm model,
it fails a save, we now have one unsaved wound, which is doubled to two.
only one has actually been allocated, via the process in the rule book which must be done for every wound, no exceptions.
the allocated unsaved wound is resolved,
then the remaining unsaved wound is now allocated as normal (unsaved wounds have already had their ONE save, please dont tangentially make the argument that a 2nd save is then possible, because that would not logically follow)

things broken by NOT allocating wounds one at a time:
1. RAW is one wound is allocated at a time
2. RAW is a model is removed as a casualty when its wounds reaches 0, a model will reach 0 wounds before it reaches -1, or -2 or however many extra wounds are being "wasted" on it, you cannot allocate wounds on a model that has already been removed.

easysauce wrote:
only one has actually been allocated, via the process in the rule book which must be done for every wound, no exceptions.

The rules say no exceptions in your book? Which page? What paragraph explains tat they go back into the wound pool?
I'm sure you can cite permission to do so.

things broken by NOT allocating wounds one at a time:
1. RAW is one wound is allocated at a time
2. RAW is a model is removed as a casualty when its wounds reaches 0, a model will reach 0 wounds before it reaches -1, or -2 or however many extra wounds are being "wasted" on it, you cannot allocate wounds on a model that has already been removed.

I've never advocated for allocating more than one wound at a time. It would be ludicrous to do so.
You're making the mistaken assumption that the doubled wound must be in the wound pool. Find rules support.

easysauce wrote:
the problem is, people are assuming that when you double the wound in the mixed saves process, that the 2nwound is automatically allocated to the model that suffered it at the same time.

RAW is that you allocate wounds one at a time,
one wound is allocated to the swarm model,
it fails a save, we now have one unsaved wound, which is doubled to two.
only one has actually been allocated, via the process in the rule book which must be done for every wound, no exceptions.
the allocated unsaved wound is resolved,
then the remaining unsaved wound is now allocated as normal (unsaved wounds have already had their ONE save, please dont tangentially make the argument that a 2nd save is then possible, because that would not logically follow)

things broken by NOT allocating wounds one at a time:
1. RAW is one wound is allocated at a time
2. RAW is a model is removed as a casualty when its wounds reaches 0, a model will reach 0 wounds before it reaches -1, or -2 or however many extra wounds are being "wasted" on it, you cannot allocate wounds on a model that has already been removed.

No the reason it goes on the scarab (or any swarm) is the because the rule says when a swarm suffers an unsaved wound from [snip] it is multiplied to two, swarm "must" be referring to the specific model as there is no "swarm unit".
In conjunction with what I mentioned in another thread, a wound can not be "Suffered" until it has been unsaved and allocated. Until that point, it is only "caused". A wound caused is nothing until it is suffered.

Didn't realize this discussion was going on in 3 different threads. So here is what I posted to a different thread. Like I said in the other thread, this isn't my argument, just kinda how it was explained to me to get me on the fence about it.

Lets say there is a string of models conga-line-style like this.

XXXXXXXOX E

Where E is the enemy, X models are T4 swarm models with 3 wounds each and a 5+ save and O is a T5 model with 1 wound and a 2+ save. E fires a Str 8 AP- blast but do to bad luck, it only hits the closest X model. All models are in range, but only 1 is hit. What happens now?

I think that would be 1 wound, which then must be allocated to the closest model, an X (T4, W3, 5+). If it fails it's save, then that is an unsaved wound on the closest model, however X is vulnerable to blasts. What happens now?

I have not heard anyone argue that the closest model would not be dead, since the blast is double it's toughness. However, it should double the unsaved wounds, does it take the 2nd unsaved wound with it when it dies or does that second unsaved wound hit the T5 2+ save guy. Does he get a save? (Can you save on a wound twice?) Does it just hit another of the swarm models?

If the T5 is in the same group, it also uses T4.

This thread got to 14 pages because the rules are unclear and can be interpreted in several ways.

The big discussion is whether:
A) The wound to the model is doubled.
B) The wound to the unit is doubled.

My general rule of thumb is that if a YMDC-thread exceeds 10 pages, it means there is no clear ruling and you should ask your friends on how they would do it.
My group follows A.


If you would follow B, the ruling says that the unsaved wound is doubled to two unsaved wounds.
That means that O cannot use his 2+, since it's an unsaved wound and he suffers one wound.

Do not forget that for ID it does use the T5, so it will not be ID!

units are not wounded, models are,

I can see why people are having a hard time reading these rules,

but they are not unclear,

regardless of when the wound is doubled, before or after the initial wound is allocated, it has not itself been allocated, and must follow the allocation process

it is treated just like any other wound that is caused, it is simply caused at a different time,

allocating 2 wounds at a time, is illegal
allocating more wounds to a model then it has, is also illegal

Wounds are dealt to a unit and then allocated to individual models.
After that it can be saved by the individual model his saves.

The time-frame would be, according to my 6th edition rulebook:
1. Roll to hit.
2. Roll to wound.
3. 'Collect' these wounds in a "wound pool".
4. Allocate these wounds to models.
5. Use appropriate saves.
6. If the model has the Swarm rule, it gets doubled.

What you are doing is taking the left-overs from step 6 and putting them back into step 3.

Why aren't you allowed to do this:
A) The wound is not suffered or dealt, the initial wound is just multiplied by two.
B) The 'additional' wound is unsaved too, but you are placing it before the save-step.
C) Wounds are dealt in step 2 and suffered in step 4, the Swarm-rule says that it suffers two wounds. That means it is already allocated! You can't allocate a wound that is already allocated.

it is treated just like any other wound that is caused

Proof?

allocating 2 wounds at a time, is illegal

We don't allocate two at a time, we allocate ONE and that one is doubled the moment it is suffered.

allocating more wounds to a model then it has, is also illegal

The 'Swarm-Wound' is never allocated at all.

your example is only looking at mixed saves

normal process is take saves, then allocate wounds,

100% in that normal process two swarm bases will be removed from the doubling of the ID wound

in mixed saves,
all you do is allocate the wound first, then take saves, then double unsaved wounds. that 2nd wound has not been allocated, and is not specifically on the model (as say a perils or over heat wound is)



No where does it say this 2nd wound is allocated already, yes you are in fact doubling the # of unsaved wounds, but no where does it say to allocate it to the model the prior wound was allocated to, it simply does not tell you to do this,

it does say wounds are allocated one at a time, if you simply assume the 2nd wound is allocated on the already dead model, several rules have been broken
such as:

allocating more wounds to a model, after its W characteristic has reached 0

allocating more then one wound at a time

allocating the 2nd wound by assumption, as opposed to following the normal process.

assuming the swarm wound is not allocated at all makes no sense.




there is no skipping back to step three, it is simply doing the normal mixed saves process for the "swarm wound" as well.

caused wounds go into the wound pool, when a swarm suffers an unsaved template wound, an aditional wound is caused, thats the requirement to go into the pool, the wound has been caused

wounds only go away from models suffering them, or when there are no models left to suffer them,

even if ID is NOT in the equation, allocating two wounds, at one, to the same model breaks rules,

why?
you flamer a swarm that is t3 with 3 wounds with a normal flamer st 4



they suffer two hits, fail both saves, and now 4 unsaved wounds are caused,

by that logic, one base is removed, and one wound disappears, never having been allocated, or suffered, despite there being eligible models to allocate it to


Automatically Appended Next Post:
mixed saves even states
"if the model is reduced to 0 wounds, remove it as a casualty.

continue allocating wounds to the closest model"


so where has that wound gone? the model you assume it has already been allocated to is dead, and cannot have wounds in excess put on it after it is dead,


the wound pool is made up of wounds "caused" pg 14 brb, that is the only stipulation to be put into the wound pool, is a wound must be caused.

hence why causing the "swarm wound" puts it into the wound pool, it has been caused, but it has not been through allocation


so breif outline

normal process:
cause hits,
cause wounds,
wounds you cause go into the wound pool,
make saves,
unsaved wounds are doubled, causing new wounds, that go into the pool,
allocate original wound since you can only resolve one at a time legally.
repeat for the remaining wounds/unsaved wounds

mixed saves
cause hits,
cause wounds,
wounds caused go into wound pool,
allocate one,
make saves, unsaved wounds are doubled, causing additional wounds,
caused wounds go into the wound pool, finish resolving the ONE wound since you can only resolve one at a time,
repeat for the remaining wounds/unsaved wounds

Please show any allowance to add additional wounds to the wound pool after it is populated.

Please show where you can apply any model based USR to an entire unit.

These are the only two ways your example can work cheesey.

Look back at the 14 pages of this thread and you will see that the only wording that is under question is what is classified as suffered. It does say the wound is already applied as it tells you that a wound that has already been allocated and a save failed is multiplied to two. This does not break a single rule as a player you have only allocated a single wound which became two after allocation & save. You are stuck somehow thinking that this makes a nebulous wound then doesn't tell you what to do with it. If you double it at the model level after allocation and failed save there are no rules broken. There is only one wound allocated at a time then becomes two. There are many times when wounds are lost so to imply that you should never loose the possibility to do wounds is naive.

 Gravmyr wrote:
Please show any allowance to add additional wounds to the wound pool after it is populated.

where is this mythical restriction on wounds that are caused being put into a wound pool?

wounds were caused, after the initial wound, hence why being put into a pool at a later time.

the wound was caused AFTER the first wound was, so it does not need your permission to go back into any pool, because its not going "back" into anyting, it simply goes in a new pool of unsaved wounds.

the wound pool is populated many times, close combat initiative steps for one, multiple units firing for another... why you think there can be only one is odd

you are assuming there is only one wound pool, ever, which is false.

as more and/or different types of wounds are caused, more pools are made, and dealt with accordingly.


you are not "re" pooling the new wounds caused by swarms, you are making a new pool, and then dealing with it as normal.

All wounds caused must go into pools, they do not have to go into a previously made pool of wounds that may not be the same type, and that may have already been resolved

you must prove that you are allowed to do the following:

you are allowed to be allocating two wounds at once to a model,
you are allowed to be allocating more wounds to a model then it has,
you are allowed to be skipping the allocation process for wounds caused by the swarms rule by not making a pool of them and resolving them one at a time as per the rules.


in order to allocate the extra wounds caused to the same model, despite there being no allocation process, and that model being ineligible for allocation of that # of wounds

The problem is everything falls apart when you either

A) Remove ID from the scenario
B) Factor in Mixed saves

 Gravmyr wrote:

These are the only two ways your example can work cheesey.

and lets keep the insults away,

please actually address the issues instead of repetition, just because you say wounds need permission to go back into the same wound pool as other, different types of wounds, does not mean such a clause exists in 40k

you are literally saying you have to put different kinds of wounds in the same pool, which is wrong.

you cannot put the unsaved wound caused by "swarms"into the same pool as the initial wound because
they are different types for one,
they happened at different times for two,
and thirdly there is no requirement that wounds of any type caused down the line must go back into the same wound pool.

pg 14 talks about multiple pools very clearly

why you keep insisting I need permission to put wounds in the wrong pool, is beyond me, and certainly isnt proof for doing things one way for normal saves, and another way for mixed saves re:swarms +ID rules stacking







Automatically Appended Next Post:

 Happyjew wrote:
The problem is everything falls apart when you either

A) Remove ID from the scenario
B) Factor in Mixed saves

how does everything fall apart?

last few editions worked fine with ID + swarms stacking,

so does this one, nothing breaks, just means swarm paper has met swarm's rock

The argument for multiple bases being removed is that the unsaved wound goes back into the wound pool.

First, let's look at what happens when there is no ID (such as a Flamer against a T3 swarm). The template hits 1 model putting a single wound in the pool. It gets allocated to the closest model. That model has now suffered an unsaved wound. How many wounds does that model lose from its profile? What if the model only has 1 Wound left?

Next, what happens with mixed saves? Either from an IC being attached to the unit, the unit having FNP or some models in the unit being in cover. A Strength 6 blast hits a unit of T3 swarms. 1 model is out in the open and does not get a save (assume AP is strong enough). If you double the unsaved wound to 2 unsaved wounds and immediately allocate it to the next model, you are now denying that model to take a save that he should get against the wound.


Automatically Appended Next Post:
Furthermore it worked fine in the previous edition due to how wound were dealt with.

 Happyjew wrote:
The argument for multiple bases being removed is that the unsaved wound goes back into the wound pool.

First, let's look at what happens when there is no ID (such as a Flamer against a T3 swarm). The template hits 1 model putting a single wound in the pool. It gets allocated to the closest model. That model has now suffered an unsaved wound. How many wounds does that model lose from its profile? What if the model only has 1 Wound left?

Next, what happens with mixed saves? Either from an IC being attached to the unit, the unit having FNP or some models in the unit being in cover. A Strength 6 blast hits a unit of T3 swarms. 1 model is out in the open and does not get a save (assume AP is strong enough). If you double the unsaved wound to 2 unsaved wounds and immediately allocate it to the next model, you are now denying that model to take a save that he should get against the wound.


Automatically Appended Next Post:
Furthermore it worked fine in the previous edition due to how wound were dealt with.

It was also heavily debated last edition, until a FAQ finally settled the matter.

and from the wording of swarm of "each unsaved wound is doubled" to me says before allocation.

They don't just say the model removes 2 wounds instead of 1.

so from the flamer the lead model takes a wound and is removed, and the next model takes the next wound, as you still have an unsaved wound. In a mixed save unit, the lead swarm fails the save and doubles the unsaved wound. Then the created unsaved wound gets allocated to the next closest model, with or without swarm.

RAW, I guess were going to necro this thread every few weeks.
RAI, double the unsaved wounds, then allocate all of them. Based on last FAQ mentioning this.

 Happyjew wrote:
The argument for multiple bases being removed is that the unsaved wound goes back into the wound pool.

First, let's look at what happens when there is no ID (such as a Flamer against a T3 swarm). The template hits 1 model putting a single wound in the pool. It gets allocated to the closest model. That model has now suffered an unsaved wound. How many wounds does that model lose from its profile? What if the model only has 1 Wound left?

Next, what happens with mixed saves? Either from an IC being attached to the unit, the unit having FNP or some models in the unit being in cover. A Strength 6 blast hits a unit of T3 swarms. 1 model is out in the open and does not get a save (assume AP is strong enough). If you double the unsaved wound to 2 unsaved wounds and immediately allocate it to the next model, you are now denying that model to take a save that he should get against the wound.

again, thre is no need to put an unsaved wound, back into the wrong type of wound pool,

wound pools are simply made when wounds are caused, show where it says that the rules on pg 14-15 only apply once a phase? or turn ect

they do not.

your words

 Happyjew wrote:
First, let's look at what happens when there is no ID (such as a Flamer against a T3 swarm). The template hits 1 model putting a single wound in the pool. It gets allocated to the closest model. That model has now suffered an unsaved wound. How many wounds does that model lose from its profile? What if the model only has 1 Wound left?

in normal saves, RAW is 100% stacking ID with swarms to remove two bases per initial wound, since it clearly states you make saves, note how many unsaved wounds you have(which would include doubling) then allocate them.
as per pg 15

so for normal saves, RAW is clear, that yes you are screwed taking swarm against ID causing templates, it clearly states allocation happens after unsaved wounds,


mixed saves, is a different process,
which is intended you give you the benefit of better saves,
which cannot be used in a unit consisting only of swarm models with the same save,

it is worded differently then normal saves, it makes no mention of unsaved wounds by name, though we all know they are caused.

you allocate a wound to the closest model,, if applicable they get their save, if they fail the wound is resolved against them, if it takes them to 0 wounds, you remove them as a casualty. it then tells you to continue allocating wounds.

if we want to go all "literal" on the rules, mixed saves doesn't mention "unsaved wounds" being caused at all, so why double the number of "wounds" when it says "unsaved wounds" right?



in both cases, the end result, is wounds are always allocated to the closest model one at a time anyways, until it runs out of wounds, at which point you continue to allocate remaining wounds to the next closest.

so while you can argue for "Schrodinger's" swarm wounds in mixed saves, that because the swarm wound has happened after initial wound was allocated, it too must be allocated to the same model, by an assumed process. but then again, we assume we have "unsaved wounds" in mixed saves as well, since it does not use the term like the normal saves process does.

so while GW has basically worded "mixed saves" into something I agree is confusing at best, only mixed saves fails to mention "unsaved wounds".

normal saves there is no debate, since BRB tells you to allocate after unsaved wounds are caused and counted.

easysauce wrote:

 Gravmyr wrote:
Please show any allowance to add additional wounds to the wound pool after it is populated.

where is this mythical restriction on wounds that are caused being put into a wound pool?

Backwards. You need permission to do things first.
The wound pool was already populated - you've moved on. Roll To Wound (and therefore populating the Wound Pool) is step 4 of a shooting attack. Allocating is step 5. (reference pages 12, 14, and 15). Find permission to add a wound to the Wound Pool after you've moved on.

wounds were caused, after the initial wound, hence why being put into a pool at a later time.

And of course you have a rule allowing it?

the wound was caused AFTER the first wound was, so it does not need your permission to go back into any pool, because its not going "back" into anyting, it simply goes in a new pool of unsaved wounds.

There's only ever one Pool per shooting attack - unless you have a rule that references a second?

the wound pool is populated many times, close combat initiative steps for one, multiple units firing for another... why you think there can be only one is odd

It's populated once per initiative step and once per shooting attack. Is the doubled wound part of a separate shooting attack? Rule citation. Please.

you are assuming there is only one wound pool, ever, which is false.

Page 14 and 15 (where The Wound Pool is defined) disagree with you.

as more and/or different types of wounds are caused, more pools are made, and dealt with accordingly.

Citation required. You keep asserting this but as far as I can tell have never backed it up with rules. Did I miss something? Please link the post to me if I did.

you are not "re" pooling the new wounds caused by swarms, you are making a new pool, and then dealing with it as normal.

Which, from all the rules I can see, isn't legal.

All wounds caused must go into pools, they do not have to go into a previously made pool of wounds that may not be the same type, and that may have already been resolved

A resolved wound is no longer in the wound pool...

you must prove that you are allowed to do the following:

you are allowed to be allocating two wounds at once to a model,

Which I've never claimed to be able to do. This is not required.

you are allowed to be allocating more wounds to a model then it has,

The doubled wound is never allocated. You keep asserting that it is but you've never proven that.

you are allowed to be skipping the allocation process for wounds caused by the swarms rule by not making a pool of them and resolving them one at a time as per the rules.

This is creating rules out of nothing. There's only one Wound Pool per shooting attack. You are only allowed to allocate from the Wound Pool. Pretending that a wound not in the Wound Pool must be allocated has no rules basis.

in order to allocate the extra wounds caused to the same model, despite there being no allocation process, and that model being ineligible for allocation of that # of wounds

Only one wound at a time is allocated. Ever.

This idea of putting the "multiplied" wound back in the Wound Pool for further allocation has a small problem. There is nothing to distinguish this "multiplied" unsaved Wound from any other unsaved Wound in the pool, and as soon as you allocate it to a Swarm model, the USR kicks in and generates another "multiplied" Wound that gets put back in the pool, ad infinitum - Wounds that just keep on giving apparently.

anyways



its pretty clear RAW for normal saves, they do stack, since unsaved wounds are caused, and counted, before allocation, you lose twice as many swarms to ID blasts


RAW is not clear for mixed saves,

mixed saves rules do not even once mention the term "unsaved wounds"

so no abilities (FnP, swarms, ect) that trigger off of "unsaved wounds" work with mixed saves by some people's logic (i would never play this way)



they tell you to allocate wounds, before saves, true enough, makes no difference when wounds only cause one wound,

when a wound turns into two,
so we are either forced to assumed the extra one is allocated the normal way, IE closest model,
or we assume they are allocated on the same model as the original wound,


obviously we can all safely assume unsaved wounds are suffered in the end, but it technically does not say that.

so mixed saves, ask your TO, and tell GW to FAQ

but normal unmixed is clear, they stack

easysauce wrote:
its pretty clear RAW for normal saves, they do stack, since unsaved wounds are caused, and counted, before allocation, you lose twice as many swarms to ID blasts

So models suffer wounds before allocation?
How does that work?

mixed saves rules do not even once mention the term "unsaved wounds"

so no abilities (FnP, swarms, ect) that trigger off of "unsaved wounds" work with mixed saves by some people's logic (i would never play this way)

If a model is allocated a Wound and fails its save, is the wound an unsaved wound?
I'd say, "Yes, by definition."

when a wound turns into two,
so we are either forced to assumed the extra one is allocated the normal way, IE closest model,
or we assume they are allocated on the same model as the original wound,

One assumption requires inventing rules and pretending that everything works okay if you don't look at it too closely.
The other way doubles post allocation.

rigeld2 wrote:

easysauce wrote:
its pretty clear RAW for normal saves, they do stack, since unsaved wounds are caused, and counted, before allocation, you lose twice as many swarms to ID blasts

So models suffer wounds before allocation?
How does that work?

you are not reading properly, i said nothing about models suffering wounds before allocation, suffering, is not the term in the book, CAUSING and CAUSED are, those the words i am using/quoting

the rule book says for normal saves to take the save first, make a note of how many unsaved wounds are caused, then allocate the wounds.
pg 15

although I expect you to ignore this rule, as you have for 14 pages
quoted again, for your ignoring pleasure,

first off for normal saves, you take saves.
pg 15 says "first of all, the target unit gets to make one saving throw...for each wound being resolved. Make note of how many unsaved wounds have been caused."<--- rigel this is where unsaved wounds have been caused, noting how many as well, so we already know we have unsaved wounds x2

it then says next, which means next, as in after unsaved wounds have been caused

pg 15 then says "next, allocate an unsaved wound to the enemy model closest to the firing unit... if the model is reduced to 0 wounds, remove it as a casualty. Continue allocating wounds to the closest model until there are no wounds left, or the whole unit has been removed as casualties"

since after that save, unsaved wounds have been caused, the # of those unsaved wounds on the unit is doubled due to the unit being a swarm. are you interpreting "unsaved wounds have been caused" as unsaved wounds have not been caused? because that is a wrong interpretation.


mixed saves, which can only be used on mixed save units, follow different rules that swap the order of saves and allocation, causing confusion.

well there are two sides,
one assumes its allocated on the initial model,
one side assumes its allocated as normal to the closest model,

GW will FAQ this, and it will be FAQ'd to say they do stack, till then ask your opponent, or TO ect









Automatically Appended Next Post:

rigeld2 wrote:

If a model is allocated a Wound and fails its save, is the wound an unsaved wound?
I'd say, "Yes, by definition."

so "unsaved wounds" are "wounds" just like "venerable dreadnaughts" are "dreadnaughts" now?



obviously there are unsaved wounds, I said as much, thats the point

Skimmed much of this as their is 14 pages... so I'll just jump in.

Swarm is not a unit type, it's a special rule. As such it is taken into account on a per model basis. Not per unit. So until the wounds are assigned to models with this SR, they are not doubled.

DeathReaper wrote:

rigeld2 wrote:

 DeathReaper wrote:

rigeld2 wrote:
It's doubled after allocation as Swarm is a model based rule, therefore you cannot double before a model with Swarm suffers a wound.

Which it has as you roll saves in one go, with models that have the same save, before allocation.

False. Swarm is model based and therefore cannot suffer a wound until after allocation.
The unit has suffered wounds, but models have not.

But units do not suffer wounds, models do...

DeathReaper wrote:For the quoted "units do not suffer wounds, models do"?

The onus is on you to say otherwise, as units do not have a wounds value.

Do you have something that says units can suffer wounds or have a wound characteristic?

DeathReaper wrote:That answer is on P.15
"First of all, the target unit gets to make one saving throw, if it has one (see page 16), for each Wound being resolved. Make a note of how many unsaved Wounds have been caused."

Coupled with P. 16 "If the result is lower than the Armour Save value, the armour fails to protect its wearer and it suffers a Wound."

After saves are taken you suffer wounds.

So you roll to hit, roll to wound, take saves and suffer unsaved wounds that have been caused.

Many times RAW says units can suffer wounds. That is what puts them in the wound pool. DoM if I recall correctly places wounds on a unit. Rolling to wounds also puts wounds on a unit(in the pool).

Roll to hit
Roll to wounds(hits become wounds... on the unit)
Take Saves(wounds on the unit become either nothing or unsaved wounds)
Assign unsaved wounds(to models)<---- here is where the special rule comes up and you have no permission to send those wounds back to the pool(the unit). The are multiplied exactly as they are... wounds on the model.

easysauce wrote:
it does say wounds are allocated one at a time, if you simply assume the 2nd wound is allocated on the already dead model, several rules have been broken
such as:
allocating more wounds to a model, after its W characteristic has reached 0
allocating more then one wound at a time
allocating the 2nd wound by assumption, as opposed to following the normal process.
assuming the swarm wound is not allocated at all makes no sense.

The second wound is never allocated.
The second wound is never allocated.
The second wound is never allocated.
Why does that make no sense? The rule clearly says that when he suffers a wound (thus when it is allocated onto a model with the Swarm-rule) that it is multiplied.

the wound pool is made up of wounds "caused" pg 14 brb, that is the only stipulation to be put into the wound pool, is a wound must be caused.

If you want to go RAW, the wound pool is made up of wounds that are rolled for with dice.

normal process:
cause hits,
cause wounds,
wounds you cause go into the wound pool,
make saves,
unsaved wounds are doubled, causing new wounds, that go into the pool,
allocate original wound since you can only resolve one at a time legally.
repeat for the remaining wounds/unsaved wounds

So wounds are doubled before they are allocated to a model with the Swarm rule?
Lol, go break some more rules.

mixed saves
cause hits,
cause wounds,
wounds caused go into wound pool,
allocate one,
make saves, unsaved wounds are doubled, causing additional wounds,
caused wounds go into the wound pool, finish resolving the ONE wound since you can only resolve one at a time,
repeat for the remaining wounds/unsaved wounds

So you put them back in the wound pool without ANY rule that allows you to do so.
And where the hell does it say that you can only resolve one at a time?
And where does it state that you "resolve" this wound? The model that suffers a wound just suffers two wounds instead.. It's that simple! But you are the only one trolling for pages and pages when everyone already agrees.

With every "rule" you make up to allow this to happen, you immediately break another rule or three.
And people keep pointing it out, but you refuse to read it.