So I've been looking into DHD a bit lately, and why it seems that they don't work due to the order of operations, where an enemy forces you to declare Reset before you could declare any of the defensive programs. Basically, upon re-reading the rules for the Order Expenditure Sequence, then searching further in the rules, the only time the rules say that you check the requirements for declaring a skill is during the last part of the order, not at the time it is declared. Check the Important box here: http://infinitythewiki.com/en/Order_Expenditure_Sequence Now, the Zone of Control rules have explicit language about what skills you can declare, specifically only allowing Change Facing or Reset, unless the trooper has a Special Skill or piece of Equipment that can be used without LoF. This section of the rules would be entirely redundant if you couldn't declare an ARO before checking the requirements. Check the text here: http://infinitythewiki.com/en/Zone_of_Control Furthermore, to prevent complication, the BS Attack Declaration rules actually prevent you from declaring the skill without having previously generated LOF (These rules appear to be in addition to the rules found under the BS Attack skill, which has different requirements). Similar to the ZoC rules about AROs, these additional requirements seem redundant if you must check the skill requirements at the time of declaration. http://infinitythewiki.com/en/BS_Attack_Declaration Those three things make it seem like you can declare Breakwater (and other defensive programs) before you've been the target of an attack. If the enemy doesn't hack you, then you've essentially declared Idle, but if they do hack you, you can resolve the hacking program. I haven't found anything in the rules or FAQ that say you to check the requirements at any time other than when you apply the effects of the orders declared. This doesn't seem to have any effect on how other aspects of the game are played, since ZoC normally forces Change Face or Reset, it seems to only really affect defensive hacking programs.
This is false. You’re not allowed to declare a skill that’s invalid when you declare it. For instance, you’re not allowed to declare BS Attack against targets you can’t see, and then declare a Move forward to where you can see them. Edit: This same discussion occurred two forums ago.
That's a good point. The BS Attack Declaration rules actually prevent you from declaring the skill without having previously generated LOF (These rules appear to be in addition to the rules found under the BS Attack skill, which has different requirements): http://infinitythewiki.com/en/BS_Attack_Declaration That kind of further supports that normally, you do not need to meet the requirements, hence the need to write in an exception for BS Attacks. Just for the sake of argument, can you show me where in the rules it says you are required to meet the requirements at the moment the order is declared, and not only during resolution? Since I run a lot of events, I like to have all the facts I can in case someone comes to me with an argument.
I’m intrigued by your proposal but I’m not ready to jump on board. I do like that you pointed out that ZoC AROs are explicitly restricted, which gets rid of the majority of the shooting without LoF shenanigans.
While I disagree on this point, it's not actually relevant to Reset, as Reset's own text stops you from declaring Reset unless one or more of the Requirements have already been met: REQUIREMENTS A trooper can only declare Reset if at least one of these is true: The trooper is targeted by a Hacking Attack, i.e., any Attack declared using a Hacking Program. The trooper is targeted by a Comms Attack. The trooper is in the Immobilized-1 state. In his Reactive Turn, the trooper has an enemy declare or execute an Order in his Zone of Control. Although it's worth bearing in mind that (as per other recent discussions) Reset can't be declared as a 'Hacking Area ARO', so a forced Reset ARO would only apply to AROs in Zone of Control, not to AROs in Hacking Area.
The Order Expenditure Sequence says no. Specifically in the big red box: A Skill declaration is not valid if the Requirements for their execution are not met. For example, a CC Attack cannot be performed against a figure that is not in base to base contact with the attacker.
Basically, DHDs only work against impetuous players (who declare attacks as first short skill) and against attacks through Repeaters.
Kind of the point, many other rules have explicit requirements when something can be declared. It seems that normally (as per the Order Expenditure Sequence), the requirements are requirements to execute, but some skills (like BS attack and Reset) or situations (ZOC) have extra rules for what and when to declare. Gotta read the next sentence: If the Player declares a Skill and, when he applies its Effects, he realizes the Requirements are not met, then the Skill is considered null. However, the trooper who declared it still generates ARO, as if he has declared an Idle, and loses the ammunition or equipment used, if he declared the use of a Disposable weapon or piece of Equipment. This wouldn't be possible if you had to meet the requirements when the skill was declared.
The next sentence applies when requirements are met, but effects retroactively negate the skill. i.e. range, there is no range requirement for declaring a BS attack, or any hacking attack, but range is only measured after declaration so you can be found to retroactively have declared an illegal skill. The second paragraph has nothing to do with declaration failure (it being a second paragraph is a big clue that it is referring to something else) but tells you how to resolve the otherwise unmentioned situation of a valid declaration made invalid by resolution.
@mittenninja and @ijw have brought up some very interesting points, mostly that with SSL1 that Wardrivers have, and Isobel has been upgraded to a WHD, it means that anything with these programs can either already delay (SSL1/WHD), or has access to other programs worth AROing with (HD+). So really, the only downside is that a HD+ often cannot declare Breakwater in ZoC as an ARO, but has other options to fall back on.
As @solkan mentioned, we know from previous CB clarifications that Requirements must be fulfilled in order to declare a Skill. The bit you've quoted is a separate paragraph that covers things like declaring the wrong Hacking Program against someone in Holo1 state etc.
@ijw I'm not jumping in one way or the other, but if this occurred 2 forums ago, it's a ruling at least 1 edition old, and as you're more aware than most the game went through a significant revamp from N2 to N3.
N2 didn't have Requirements, it was 100% for the current edition. Solkan may have got the wrong number of forums ago.
Or for models with SSL1. Or vs attacks from Marker state enemies. Or vs Possessed TAGs. Or vs AD troopers. Or vs Guided BS Attacks. ;) But yes, the requirements on Shield-2/3 programs should be changed so that these programs are more generally useful. The issue isn't DHDs (which are designed to primarily provide access to Shield-1 programs) but Shield-2/-3 programs. I'd also like to see Kaleidoscope and Reboot become a Shield-2 programs rather than Gadget-EVO programs. As this would allow DHDs/WHDs etc to be more effective defensively.
How does that even happen with the requirement to reveal your Hackable status when in a hacking area?
Even this sentence actually implies you can make the Declaration. It doesn't tell you that you can't make a declaration if it's not valid, it tells you that you can't perform a Declaration that you did make that is invalid. For that to be the case you have to be able to make it. And the following sentence even emphasises it. It may not be the intent, but that is what is written. Everyone here disputing that is just repeating what they already think is established, but not providing any actual proof that that is true other than their established opinion. Meanwhile the OP is actually demonstrating that the rules actually say something different.
#1 I ARO with my chain rifle against that troop you just activated... there are 3 of your troops in the middle. Oh, drat. Your activated troop was outside of the chain rifle template. I eat 3 combi shots to the face, unopposed, and your three troopers are safe from the chain rifle impact. #2 I declare Oblivion against Achilles with my Camo AHD when he shoot against another of my troops. Drat, Achilles was outside of my hacking area, my troop gets out of camo (declared something other than a short movement order) and performs an Idle. I doubt I can declare "I oblivion you" with my Krakot... at least against an enemy outside my LoF and with no grenades to throw ;)
The paragraph in the red box literally says the declaration must be valid which, when that paragraph is allowed to stand on its own, in a very literal way says that a declaration made without requirements being met is immediately invalidated. The last paragraph puts doubt regarding when this is evaluated, simply because it doesn't tell you whether evaluation of validity is done once or several times. A skill becoming invalidated during an order is such a rare occurrence that it's not necessarily the most obvious interpretation that the last paragraph is referring to that occurrence rather than the general case of, say, declaring BS Attack prior to gaining LOF. However, I don't think we even want to have skill declarations without first meeting the requirements simply because of what that'll risk doing in conjunction with All At Once and conditional movement like Dodge.
To me the easiest solution is to just give WHD/DHD's a special rule that allows them to always declare a shield program when they could reset instead. They are so infrequently used that I don't imagine this would break anything and give them at least SOME niche.
WHDs have pseudo-sixth sense, so they can delay their ARO until after the attacker’s second skill. It doesn’t help in their own active turn if they are taking an ARO from a sixth sense model. Note that Reset suffers this same issue - there’s a thread about it if you want to slog through that. At the time HSN3 came out I loudly objected to this “fix” instead of an edit to the SHIELD program requirements; I feel like it’s solving the wrong problem.
