Rule changes I'd like to see in GG3.

[Tors]

I would like for gaining grounds to stay a tournament format document like it has been instead of beeing converted into some kind of core rule errata testground.

Please provide options for the tournament structure part and rotating s&s including details for scoring - like excluding or limiting scoring options for summons - but keep actual rule changes within errata and new editions.

[Maniacal_cackle]

8 hours ago, Angelshard said:

 I'm just not sure if adding another decision to the pregame of an already time consuming game is the best way to go. 

Could just stick with the original suggestion, change the timing of declaring deployment zones.

[solkan]

1 hour ago, PiersonsMuppeteer said:

Maybe saying it kills the possibility of incomplete rules understanding causing an infinite loop is better, but I think that having them once per turn could allow for some streamlining of rules that prevent the loop (or just cut down on sections of rules needed to reference during those scenarios). Is there any big detracting factor to Demise effects not already once per turn being adjusted to once per turn?

To the start with, you’d have just as much to keep track of for the bomb-type demises, so making those once per turn wouldn’t actually make things simpler.

And then there’s all of the demises like Leveticus that are not once per turn.

[Adran]

1 hour ago, PiersonsMuppeteer said:

Maybe saying it kills the possibility of incomplete rules understanding causing an infinite loop is better, but I think that having them once per turn could allow for some streamlining of rules that prevent the loop (or just cut down on sections of rules needed to reference during those scenarios). Is there any big detracting factor to Demise effects not already once per turn being adjusted to once per turn?

Had you thought there was an infinite loop before that thread? 

You need to be quite in the nitty gritty of the rules to see it as a possibility, so I doubt it's really an issue. 

Where as putting once per turn on demise explosive would confuse lots of people.

 It also may not let you change the rule because it does more than just stop infinite demise. 

[PiersonsMuppeteer]

13 minutes ago, solkan said:

To the start with, you’d have just as much to keep track of for the bomb-type demises, so making those once per turn wouldn’t actually make things simpler.

And then there’s all of the demises like Leveticus that are not once per turn.

I think it would reduce things to be resolved at another time, but I also think it would be easier to resolve Blast damage to model A and all other resulting damage prior to moving onto Blast damage on model B. Maybe I’m a minority? 

Also maybe targeting Demise to more concretely stop Demise loop is better adjusted by removing Step 6 of damage timing and making Killed a game term. It has always seemed odd to me that Killed isn’t a game term with the steps broken down in the Killed section of the rules instead of in damage timing.

7 minutes ago, Adran said:

Had you thought there was an infinite loop before that thread? 

You need to be quite in the nitty gritty of the rules to see it as a possibility, so I doubt it's really an issue. 

Where as putting once per turn on demise explosive would confuse lots of people.

 It also may not let you change the rule because it does more than just stop infinite demise. 

No, but apparently I might have been unique in my interpretation since it was simple to track and didn’t need the use of sequential effects to stop a Demise loop. Damage timing has all the language required imo.

[Adran]

11 hours ago, PiersonsMuppeteer said:

I think it would reduce things to be resolved at another time, but I also think it would be easier to resolve Blast damage to model A and all other resulting damage prior to moving onto Blast damage on model B. Maybe I’m a minority? 

Maybe. I'm fairly sure most people would instinctively expect damage from explosion 1 to all happen before damage from explosion 2 if explosion 2 was caused by explosion 1.

I would think you would have to put similar rules in place to get the effects your prefered way as to the rule book way.  Trying to resolve simultaneous things sequentially is going to lead to some strange cases, which ever way you do it, and you need to provide rules to order them. 

 

11 hours ago, PiersonsMuppeteer said:

Also maybe targeting Demise to more concretely stop Demise loop is better adjusted by removing Step 6 of damage timing and making Killed a game term. It has always seemed odd to me that Killed isn’t a game term with the steps broken down in the Killed section of the rules instead of in damage timing.

There isn't and has never been (to my knowledge) a "demise loop". no version of the rules during the public beta, or since publishing and errata has had a "demise loop". If you change the rules, it is possible to create a "demise loop", but that's a bad thing, so lets not do that. If your changing of the rules causes a demise loop, then it may well cause other unexpected problems in the damage steps so needs to be looked at carefully. 

Killed is a game term. Its covered on page 25. The rules for it are there. If you read that section you should hopefully be able to calculate what happens in step 6 exactly the same way as page 34 tells us. There are occasional unclear things for some people, but you can certainly make the 2 correlate if you read them side by side

I would say its pretty sensible to give the detailed killed timing steps in the damage timing steps when you are trying to explain the timing, as almost every single instance you need to care about the timing in more detail than explained on page 25 is when damage is involved. Killed is a common outcome of being damaged, and so its not too surprising to include it in the damage timing. 

 

I agree damage timing has the rules needed. It had the rules needed before errata, and has them after errata, but in the rules question that started this debate, the questioner had assumed each models blast damage step was an entirely separate step. so that the damage from demise should happen before all the blast. The rules in the sequential effects section were enough to convince them that the Blast damage as a whole was the "initial step", rather than the blast damage to Model A. 

[PiersonsMuppeteer]

On 9/23/2021 at 3:56 AM, Adran said:

Maybe. I'm fairly sure most people would instinctively expect damage from explosion 1 to all happen before damage from explosion 2 if explosion 2 was caused by explosion 1.

I would think you would have to put similar rules in place to get the effects your prefered way as to the rule book way.  Trying to resolve simultaneous things sequentially is going to lead to some strange cases, which ever way you do it, and you need to provide rules to order them. 

 

There isn't and has never been (to my knowledge) a "demise loop". no version of the rules during the public beta, or since publishing and errata has had a "demise loop". If you change the rules, it is possible to create a "demise loop", but that's a bad thing, so lets not do that. If your changing of the rules causes a demise loop, then it may well cause other unexpected problems in the damage steps so needs to be looked at carefully. 

Killed is a game term. Its covered on page 25. The rules for it are there. If you read that section you should hopefully be able to calculate what happens in step 6 exactly the same way as page 34 tells us. There are occasional unclear things for some people, but you can certainly make the 2 correlate if you read them side by side

I would say its pretty sensible to give the detailed killed timing steps in the damage timing steps when you are trying to explain the timing, as almost every single instance you need to care about the timing in more detail than explained on page 25 is when damage is involved. Killed is a common outcome of being damaged, and so its not too surprising to include it in the damage timing. 

 

I agree damage timing has the rules needed. It had the rules needed before errata, and has them after errata, but in the rules question that started this debate, the questioner had assumed each models blast damage step was an entirely separate step. so that the damage from demise should happen before all the blast. The rules in the sequential effects section were enough to convince them that the Blast damage as a whole was the "initial step", rather than the blast damage to Model A. 

Killed is a game term, but it's not really used as one. Case in point, the Damage Timing rules for determining if a model is killed are different than the rules for when a model is Killed. If Killed was a game term in the same aspect as Place, Step 5 would cover when a model is Killed because it is an effect based on a model being reduced to a specific health (0). Honestly, if Step 6 was removed and the a/b/c/d placed under Step 5, there wouldn't be the possibility of a loop when changing rules. Something at 0 can't be reduced to 0, so Killed will only happen once and the need for multiple rules to govern a VERY specific situation is no longer needed.

I had never thought a demise loop had existed until you mentioned it in another thread, and thought that it had been an issue previously. Sorry for that confusion, was trying to not start a "does a loop exist debate" by providing a solution that keeps it from being a possibility if changes were made.

[Maladroit]

Slightly weird one, because it doesn't really matter (you can just choose two different schemes), but I don't think assassinate and vendetta are a good combination of schemes in Henchman Hardcore. They are too similar and there is usually not a mystery about the vendetta target. I get that a 3' x 3' board is a lot of space and they probably wanted to use schemes that forced crews to engage, but I'd like a bit more variety.

[solkan]

On 9/24/2021 at 3:14 PM, PiersonsMuppeteer said:

Killed is a game term, but it's not really used as one. Case in point, the Damage Timing rules for determining if a model is killed are different than the rules for when a model is Killed. If Killed was a game term in the same aspect as Place, Step 5 would cover when a model is Killed because it is an effect based on a model being reduced to a specific health (0). Honestly, if Step 6 was removed and the a/b/c/d placed under Step 5, there wouldn't be the possibility of a loop when changing rules. Something at 0 can't be reduced to 0, so Killed will only happen once and the need for multiple rules to govern a VERY specific situation is no longer needed.

I had never thought a demise loop had existed until you mentioned it in another thread, and thought that it had been an issue previously. Sorry for that confusion, was trying to not start a "does a loop exist debate" by providing a solution that keeps it from being a possibility if changes were made.

One of the things you're not paying attention to is that a model at 0 wounds mechanically cannot suffer damage--any damage it suffers will be ignored.  Because you're ignoring all of the damage, the model won't loop through the damage sequence:

Quote

When a model suffers damage, it loses Health equal to the amount of damage it suffered. A model may not have its Health reduced below 0. If it would suffer damage that would bring its Health below 0, any additional damage is ignored. When a model reaches 0 Health, it is killed.

While things like the timing sequences are useful for specifying some of the complicated rules interactions, those sequences need to be understood in the context of the rest of the rules.  For instance, the situation of a model at 0 wounds remaining being subject to a "target suffers X damage" event becomes a non-event because of the statement in damage reduction:

Quote

If a model suffers 0 damage, it is not considered to have suffered damage.

when it combines with the fact that all of X damage was ignored.

The crucial limitation of things like the Damage Timing is that they don't tell you when to give up on the sequence.  And look at steps 4 and five:

Quote

4.  The model lowers its Health by an amount equal to the final damage amount.

5.  Any effects that happen after a model is damaged or after a model is reduced to a specific Health, resolve at this point.

According to the damage reduction rules, if you didn't suffer any damage at step 4, you weren't damaged.  That means that you're supposed to stop without resolving step five.

Likewise, if a model is healed in Step 6a, you're supposed to stop and not continue resolving the rest of Step 6. 

I'm just saying all of this to come to the point that a loop appears to exist because the damage timing chart doesn't say when to stop the process.  Addressing that oversight would probably be the most direct way to address the issue.

 

[PiersonsMuppeteer]

1 hour ago, solkan said:

One of the things you're not paying attention to is that a model at 0 wounds mechanically cannot suffer damage--any damage it suffers will be ignored.  Because you're ignoring all of the damage, the model won't loop through the damage sequence:

While things like the timing sequences are useful for specifying some of the complicated rules interactions, those sequences need to be understood in the context of the rest of the rules.  For instance, the situation of a model at 0 wounds remaining being subject to a "target suffers X damage" event becomes a non-event because of the statement in damage reduction:

when it combines with the fact that all of X damage was ignored.

The crucial limitation of things like the Damage Timing is that they don't tell you when to give up on the sequence.  And look at steps 4 and five:

According to the damage reduction rules, if you didn't suffer any damage at step 4, you weren't damaged.  That means that you're supposed to stop without resolving step five.

Likewise, if a model is healed in Step 6a, you're supposed to stop and not continue resolving the rest of Step 6. 

I'm just saying all of this to come to the point that a loop appears to exist because the damage timing chart doesn't say when to stop the process.  Addressing that oversight would probably be the most direct way to address the issue.

 

I agree with most of your points except that the issue is two definitions of Killed exist: (1) “reduced to 0 health” in Killed, and (2) “at 0 health” in Damage Timing. If there was only the first, there wouldn’t be a need to add additional checks to continue damage timing or not. 

Also, a model can suffer damage while at 0 health. Any effect which references “suffers X damage” is considered after damage reduction as per Damage rules. So any effect which causes damage has to pass through Steps 1-5 of Damage Timing. A model with 0 health that suffers 2 damage after damage reduction will not lower their health in Step 4 as the damage is ignored, but will resolve an “after suffering damage” effect in Step 5 because they suffered 2 damage. With that in mind, I think adding an escape to damage timing in Step 4/5 for 0 damage suffered makes the rules more complex than reducing killed via damage to one definition.

 

[Adran]

4 hours ago, PiersonsMuppeteer said:

I agree with most of your points except that the issue is two definitions of Killed exist: (1) “reduced to 0 health” in Killed, and (2) “at 0 health” in Damage Timing. If there was only the first, there wouldn’t be a need to add additional checks to continue damage timing or not. 

Also, a model can suffer damage while at 0 health. Any effect which references “suffers X damage” is considered after damage reduction as per Damage rules. So any effect which causes damage has to pass through Steps 1-5 of Damage Timing. A model with 0 health that suffers 2 damage after damage reduction will not lower their health in Step 4 as the damage is ignored, but will resolve an “after suffering damage” effect in Step 5 because they suffered 2 damage. With that in mind, I think adding an escape to damage timing in Step 4/5 for 0 damage suffered makes the rules more complex than reducing killed via damage to one definition.

 

FAQ section 1 q 7. disagrees with you

7. When determining how much damage a model suffered from an effect (for purposes such as the Necrotic Decay Trigger), is damage reduction accounted for?

a) Yes. Whenever an effect is referring to the amount of damage a model suffered from an effect, it is always referring to the amount the model’s Health was lowered in Step 4 of Damage Timing (pg. 34). It is important to note a model’s Health can never be reduced below 0. As such, excess damage past 0 is not treated as damage suffered by the model

 

 

(Also there is another "killed" definition which is caused by execute and similar triggers that is not based off health. Being reduced to 0 health "Kills" you, but it is not the only way to kill a model )

[Maladroit]

16 minutes ago, Adran said:

(Also there is another "killed" definition which is caused by execute and similar triggers that is not based off health. Being reduced to 0 health "Kills" you, but it is not the only way to kill a model )

That would be in the section titled Killed for anyone who wants the reference (Page 25 DRB):

"Killed
Models are most often killed as a result of being reduced to 0 Health, but some game effects can instantly kill
models regardless of their Health."

To add another one, a model can also be killed by being buried at the end of the game . . . .

[Angelshard]

I'd love if they added a timing prefix to every ability, action and trigger that corresponded with the detailed timing chart, so there was never any doubt when it would resolve. And if a trigger resolves in different steps. Each sentence should have a prefix. 

Also I wish they'd kept to their own rule, that abilities, actions and triggers that are identical have the same name. 

It really annoys me that Dashel2 and sandworm essentially have the same ability, but for two different keywords. They could easily have formulated it so that both had the same name. 

[Da Git]

If they decided to bring a kill-based strategy back, what about if the win-condition (eg, drop head marker, bounty tokens, etc) proc'd off the first time a model was reduced to 0 HP? That way things that demise replace wouldn't be as super oppressive as they were in Collect the Bounty (I'm looking right at you Levie, 2 Deso Engines, & A&D!).

  

On 10/1/2021 at 11:56 PM, Angelshard said:

I'd love if they added a timing prefix to every ability, action and trigger that corresponded with the detailed timing chart, so there was never any doubt when it would resolve. And if a trigger resolves in different steps. Each sentence should have a prefix. 

Also I wish they'd kept to their own rule, that abilities, actions and triggers that are identical have the same name. 

It really annoys me that Dashel2 and sandworm essentially have the same ability, but for two different keywords. They could easily have formulated it so that both had the same name. 

I've always wanted this for Toshiro's Leadership ability. That way Death Marshal Recruiters could lose their replace mechanic (which doesn't really seem to match the fluff... turning your colleague into Death Marshals) and give him Leadership (Death Marshal) to show that he's training the new recruits. Although this probably isn't needed as much now with Death-Touched J buffing Death Marshals.

 

[Maniacal_cackle]

May have been mentioned already, but...

Being able to relent your own shockwaves should be added to the rules. For recent releases they've clearly taken to the idea that you should be able to benefit from your own shockwave with no flip, so it'd be good to see that retroactively applied to everyone.

I don't imagine it'd break too many things?

EDIT: I suppose for some, the failure being automatic is keyword locked (like Maxine 2), so that's a consideration... But still, on balance it feels like it'd be worth it unless they bulk update existing shockwaves.

[touchdown]

You should be allowed to use focus on simple duels.

[Rufess]

1 hour ago, touchdown said:

You should be allowed to use focus on simple duels.

Like this, but then should Distracted affect simple duels in similar manner as well?