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.

 JohnnyHell wrote:
And once again, the rules aren't written in code, so there's limited benefit in translating into code. All you're doing is codifying your interpretation, which is then no longer the original rule. This forum is not for rewriting the rules, it's for interpreting and figuring out how to play them. YMMV, but that's how I see it.

No, turning something into pseudocode allows you to remove the ambiguity from the rules by applying the truest meaning of the rules. It's not codifying my interpretation, it's programmatically generating an unambiguous interpretation.

edwardmyst wrote:

Ice_can: I would like to first point out I wasn't arguing against any form of overriding, only I think it is being interpreted to overwrite far more than it does. Overwrite must happen. To compare: White Scars overwrite the portion of the charge rules that say a unit that falls back cannot charge, and that is it. It does not overwrite the rules for 12" distance, etc. I feel the interpretation here is overreaching what is replaced if that makes sense. Hmmm or are people interpreting it exactly that way, and my white scars who fall back can now choose as a target a unit that is outside of 12"? (this could matter with all the consolidate etc shenanigans)

I was trying to think it out in a way that results in a playable stratageum.
It's unfortunately a part of GW rules I have come to just expect and have to spend way too much time trying to interpret what the rules mean when GW should be publishing clear rules given how much money people are spending on rulebookd etc.

MachinaMandala wrote:
To put it in plain English. There's a bowl of apples on the table in the kitchen. I say to you, "As long as you are in the kitchen, you may not take any apples." Then I say to you, "You may take apples." What is your interpretation of this?

I need a fishing pole or a trash picker so I can grab an apple from the living room, duh! Clearly, I can take an apple and I cannot so I cannot.

MachinaMandala wrote:

 JohnnyHell wrote:
And once again, the rules aren't written in code, so there's limited benefit in translating into code. All you're doing is codifying your interpretation, which is then no longer the original rule. This forum is not for rewriting the rules, it's for interpreting and figuring out how to play them. YMMV, but that's how I see it.

No, turning something into pseudocode allows you to remove the ambiguity from the rules by applying the truest meaning of the rules. It's not codifying my interpretation, it's programmatically generating an unambiguous interpretation.

You verify JohnnyHell's point. "to remove the ambiguity from the rules" means you're changing what the rules are saying in English. if there's ambiguity, you're changing the rules by removing the ambiguity.

 doctortom wrote:

MachinaMandala wrote:

 JohnnyHell wrote:
And once again, the rules aren't written in code, so there's limited benefit in translating into code. All you're doing is codifying your interpretation, which is then no longer the original rule. This forum is not for rewriting the rules, it's for interpreting and figuring out how to play them. YMMV, but that's how I see it.

No, turning something into pseudocode allows you to remove the ambiguity from the rules by applying the truest meaning of the rules. It's not codifying my interpretation, it's programmatically generating an unambiguous interpretation.

You verify JohnnyHell's point. "to remove the ambiguity from the rules" means you're changing what the rules are saying in English. if there's ambiguity, you're changing the rules by removing the ambiguity.

This guy gets it!

 doctortom wrote:
You verify JohnnyHell's point. "to remove the ambiguity from the rules" means you're changing what the rules are saying in English. if there's ambiguity, you're changing the rules by removing the ambiguity.

Completely wrong. If you like, consider it generating the truest interpretation based off of rules writing. Look up technical specification writing if you want to learn about this sort of thing.

Essentially, I'm not removing ambiguity from the sentence, but removing it from possible erroneous human interpretation.

MachinaMandala wrote:

 doctortom wrote:
You verify JohnnyHell's point. "to remove the ambiguity from the rules" means you're changing what the rules are saying in English. if there's ambiguity, you're changing the rules by removing the ambiguity.

Completely wrong. If you like, consider it generating the truest interpretation based off of rules writing. Look up technical specification writing if you want to learn about this sort of thing.

Essentially, I'm not removing ambiguity from the sentence, but removing it from possible erroneous human interpretation.

The "truest" interpretation does not make it true. It's only an interpretation which can easily strip out ambiguity. "Possible erroneous human interpretation" - who decides it's erroneous? In some cases it might be obviious, but that could be you injecting your own bias in to strip out what you see as erroneous human interpretation but could be a legitimate alternative interpretaion.

We're here to discuss the rules. We're not here to discuss code. Arguing about whether to talk code is a digression from the actual issue.

 doctortom wrote:
The "truest" interpretation does not make it true. It's only an interpretation which can easily strip out ambiguity. "Possible erroneous human interpretation" - who decides it's erroneous? In some cases it might be obviious, but that could be you injecting your own bias in to strip out what you see as erroneous human interpretation but could be a legitimate alternative interpretaion.

We're here to discuss the rules. We're not here to discuss code. Arguing about whether to talk code is a digression from the actual issue.

It's pretty obvious you've got your own completely wrong idea that, no matter how many times you're shown otherwise, you'll never move away from.

So I'll just summarise once more for anyone who'd actually like to learn:

When we are discussing rules, we are discussing code. Code (and the whole field of computing as a science) is a digital representation of some physical or logical procedure. In this case, we are translating the logical rules into pseudocode form to make the order of activation and the logical operations obvious.

But yeah, arguing about whether to talk code is a digression. It should be a non-issue. We have a clear ruleset that can be represented logically. We have a clear sequence of operations. We have words that can be ambiguous in general English but when represented in logical form are not. Just because you cannot grasp the concept that you have read something wrong and that there's a clear and linear order of operations and results, that does not mean there isn't one. It just means that you are ignorant of it.

TL;DR: Learn what computer science is before arguing with someone who has a degree in it.

MachinaMandala wrote:

 doctortom wrote:
The "truest" interpretation does not make it true. It's only an interpretation which can easily strip out ambiguity. "Possible erroneous human interpretation" - who decides it's erroneous? In some cases it might be obviious, but that could be you injecting your own bias in to strip out what you see as erroneous human interpretation but could be a legitimate alternative interpretaion.

We're here to discuss the rules. We're not here to discuss code. Arguing about whether to talk code is a digression from the actual issue.

It's pretty obvious you've got your own completely wrong idea that, no matter how many times you're shown otherwise, you'll never move away from.

So I'll just summarise once more for anyone who'd actually like to learn:

When we are discussing rules, we are discussing code. Code (and the whole field of computing as a science) is a digital representation of some physical or logical procedure. In this case, we are translating the logical rules into pseudocode form to make the order of activation and the logical operations obvious.

But yeah, arguing about whether to talk code is a digression. It should be a non-issue. We have a clear ruleset that can be represented logically. We have a clear sequence of operations. We have words that can be ambiguous in general English but when represented in logical form are not. Just because you cannot grasp the concept that you have read something wrong and that there's a clear and linear order of operations and results, that does not mean there isn't one. It just means that you are ignorant of it.

TL;DR: Learn what computer science is before arguing with someone who has a degree in it.

The problem with turning anything into pseudo code or actual code is not that the (pseudo) code isn't clear.
The issue is that the transition from concept to code is still an interpretation, and interpretations are always subjective and prone to misunderstandings.

The only one who will be able to judge whether or not the code fits the requirement is the author of the requirement, not the coder.
In other words: just because your program runs well doesn't mean you've succeeded at implementing the requirements.

Tangentially, this reminds me of a classic urban legend about programming.

The army requires a program to notify users that they've been signed up for the draft. To be eligible for the draft, you had to be at least 18 years old "or" less than 25 years old.

The programmer was replaced when he pointed out that the "or" should have been an "and."

 MagicJuggler wrote:
Tangentially, this reminds me of a classic urban legend about programming.

The army requires a program to notify users that they've been signed up for the draft. To be eligible for the draft, you had to be at least 18 years old "or" less than 25 years old.

The programmer was replaced when he pointed out that the "or" should have been an "and."

There's a sign in one of the restrooms at my workplace that says to turn off the light if it's after 5pm or noone's left in the restroom.

nekooni wrote:

The problem with turning anything into pseudo code or actual code is not that the (pseudo) code isn't clear.
The issue is that the transition from concept to code is still an interpretation, and interpretations are always subjective and prone to misunderstandings.

The only one who will be able to judge whether or not the code fits the requirement is the author of the requirement, not the coder.
In other words: just because your program runs well doesn't mean you've succeeded at implementing the requirements.

Hey, sure that's the case if this is me trying to turn a business' poorly understood paper system (with no real process for half of it) into a computational one whilst I have a bunch of conflicting user accounts for how they actually submit everything.

However, it's not the case in a situation where the system is a set of agreed upon clear linear rules.

The only assumption I've made is that later rules overrule earlier rules in terms of contradictions. If that was not the case then even the 2 shots portion of the stratagem wouldn't work, as I pointed out earlier.

And now the whole thread has derailed into discussing someone's coding attempt and not the rule, further illustrating my point.

Shall we just stick to discussing the rule in question, not homebrew code versions of it?

please.

Nevermind, moderator has stepped in and I can't be bothered with someone who's now obviously just trolling.

I've seen zero trolling, just people trying to stay on topic.

On topic, I interpret the rule as not overriding the rest of the Shooting Phase restrictions. So it doesn't permit you to e.g. fire your weapons if within 1" of an enemy, at an enemy unit within 1" of one of your units, shoot closest visible if there's a nearer unit out of LOS etc. So it has a more limited application than it first appears, though can still be very useful in the right circumstances. Just check all that stuff before declaring it so you don't find yourself down 2CP and unable to utilise it.

So you interpret it in a way that it doesn't state at all on the stratagem whilst also ignoring the logic that, in that case, the unit shouldn't be able to shoot twice and should also shoot at any target it wants to within the base rules.

You're trolling.

MachinaMandala wrote:
I'm just snipping out this past because I feel it summarises your whole post.

In this case, we have:
Rule A) Core Rulebook: A unit who advances, falls back or is within 1" of an enemy unit may not be chosen to shoot.
Rule B) Core Rulebook: A unit may shoot once.
Rule C) Stratagem: This unit may be chosen to shoot.
Rule D) Stratagem: This unit may shoot twice.

There are two sets of contradictory rules here. A and C can be contradictory and B and D are directly contradictory (as there is no statement about overriding existing rules on either of them), so much so that they cannot exist within the same game state.

Which ones do you pick to interpret and why? If you interpret [A+D] then [B+C] is an equally valid choice, as either way you are ignoring half the rules in both sources. The only reasonable interpretation is either [A+B] or [C+D], the former of which makes about 90% of stratagems literally useless and the latter of which is the only sensible interaction, as the use of the stratagem overrides all other rules.

MachinaMandala wrote:
EDIT: To put it in plain English. There's a bowl of apples on the table in the kitchen. I say to you, "As long as you are in the kitchen, you may not take any apples." Then I say to you, "You may take apples." What is your interpretation of this?

The Stratagem gives explicit permission to override the Core Rules to shoot twice, and adds a condition (shoot closest unit only).

It does not give permission to override other rules, so why should they not apply?

(P.S. I am not trolling - you might want to look up the forum's Rule 1. You don't get to call me names just because you disagree.)

 JohnnyHell wrote:
The Stratagem gives explicit permission to override the Core Rules to shoot twice, and adds a condition (shoot closest unit only).

It does not give permission to override other rules, so why should they not apply?

Where does it give permission to override the core rules to shoot twice?

Stratagem wrote:Use this Strategem at the start of your shooting phase. Pick a Vior'la Sept Infantry unit from your army. That unit may be chosen to shoot twice this phase, but all models in the unit must target the closest enemy unit each time they do so.

Can you quote it to me? Because I know you can't, as there's nothing that says "ignoring normal shooting rules". You either accept that concept of the whole stratagem overruling the core rules is valid or you make the whole stratagem void.

This is what your entire argument is based on, by the way. You state that it's necessary to have a specific statement saying that they ignoring normal unit choice shooting rules but then you ignore the reality that none of the other statements have anything stating that they ignore the core rules. You are being self-contradictory and don't seem to understand that.

 JohnnyHell wrote:
(P.S. I am not trolling - you might want to look up the forum's Rule 1. You don't get to call me names just because you disagree.)

I'm not calling you names, I'm stating that you're trolling, which you are. Trust me, I'm giving you the full benefit of the doubt by stating that you're trolling. The other option is much less charitable.

You might like to look up YMDC's "tenets", though, as you repeatedly break several of them throughout this entire thread.

 Lorek wrote:

Tenets of You Make Da Call (YMDC):

1. Don't make a statement without backing it up.
- You have to give premises for a conclusive statement; without this, there can be no debate. For more detail on how to actually create a logically supported conclusion, please read this article on how to have an intelligent rules debate.

1a. Don't say that someone is wrong, instead you explain why you think their opinion is wrong. Criticize the opinion, not the person.

4. Rules as Written are not How You Would Play It. Please clearly state which one you are talking about during a rules debate, and do not argue a RAW point against a HYWPI point (or vice-versa).
- Many arguments can be avoided if this is made clear. Don't assume you know the point your opponent is arguing about.

6. Dictionary definitions of words are not always a reliable source of information for rules debates, as words in the general English language have broader meanings than those in the rules. This is further compounded by the fact that certain English words have different meanings or connotations in Great Britain (where the rules were written) and in the United States. Unless a poster is using a word incorrectly in a very obvious manner, leave dictionary definitions out.

A Few Definitions
For those who haven't seen these terms before.

Rules As Written - This refers to playing by the strict letter of the rules, which can lead to odd or counterintuitive situations.

How You Would Play It - This refers to taking small liberties with the rules to smooth out the odd or counterintuitive situations listed above.

I am 1 more lazy yelling of the word "troll", or any other rudeness, away from throwing out bans and locking the thread. Take a breath and grow up

"This unit may be chosen to shoot twice"

This gives explicit permission to override a normal core rule, that you may shoot once. If we can't agree on this I'm afraid you're off to a non-starter with the rest of your post.

All special rules override or amend basic rules. It's how they work. But it's entirely possible to override some elements whilst leaving others as usual.

For example, the Ravenwing strat that lets you Advance and shoot with no penalty overrides that element (Advancing and firing non-Assault weapons, and ignoring the -1 associated with Assault normally), but doesn't suddenly let you target Characters who aren't the closest unit. Overriding one core rule doesn't throw them all out with the bath water.

RAW, the Ravenwing example is a false analogy.

Choosing a unit to shoot and choosing targets are separate steps.

The problem is GW uses "shoot" and "choose to shoot" interchangeably.

So "Advance and shoot" presumably means "may be chosen to shoot even if the unit Advanced." "May be chosen to shoot twice" alters/debatably replaces Step 1 (Choose a unit) entirely.

 JohnnyHell wrote:
"This unit may be chosen to shoot twice"

This gives explicit permission to override a normal core rule, that you may shoot once. If we can't agree on this I'm afraid you're off to a non-starter with the rest of your post.

You're right, it gives permission to override normal core rules (two of them, in fact). We can completely agree on that! Good job.

Does it at any point state explicitly it overrides core rules, though?

 JohnnyHell wrote:
All special rules override or amend basic rules. It's how they work. But it's entirely possible to override some elements whilst leaving others as usual.

You're correct! Good job, again! I'm proud of you.

Are we allowed to pick and mix what core rules are overridden? Or do we have to accept all the rules that are contradicted are overridden?

 JohnnyHell wrote:
For example, the Ravenwing strat that lets you Advance and shoot with no penalty overrides that element (Advancing and firing non-Assault weapons, and ignoring the -1 associated with Assault normally), but doesn't suddenly let you target Characters who aren't the closest unit. Overriding one core rule doesn't throw them all out with the bath water.

I'm not sure of this particular example, but you're getting there! Good boy!

However, you're missing a key point which I'll just quote myself back to you again so hopefully this time you'll read it:

MachinaMandala wrote:
I'm just snipping out this past because I feel it summarises your whole post.

In this case, we have:
Rule A) Core Rulebook: A unit who advances, falls back or is within 1" of an enemy unit may not be chosen to shoot.
Rule B) Core Rulebook: A unit may shoot once.
Rule C) Stratagem: This unit may be chosen to shoot.
Rule D) Stratagem: This unit may shoot twice.

There are two sets of contradictory rules here. A and C can be contradictory and B and D are directly contradictory (as there is no statement about overriding existing rules on either of them), so much so that they cannot exist within the same game state.

Which ones do you pick to interpret and why? If you interpret [A+D] then [B+C] is an equally valid choice, as either way you are ignoring half the rules in both sources. The only reasonable interpretation is either [A+B] or [C+D], the former of which makes about 90% of stratagems literally useless and the latter of which is the only sensible interaction, as the use of the stratagem overrides all other rules.

MachinaMandala wrote:
EDIT: To put it in plain English. There's a bowl of apples on the table in the kitchen. I say to you, "As long as you are in the kitchen, you may not take any apples." Then I say to you, "You may take apples." What is your interpretation of this?

Did you read it this time? I'd read it if I was you.

 MagicJuggler wrote:
RAW, the Ravenwing example is a false analogy.

Choosing a unit to shoot and choosing targets are separate steps.

The problem is GW uses "shoot" and "choose to shoot" interchangeably.

So "Advance and shoot" presumably means "may be chosen to shoot even if the unit Advanced." "May be chosen to shoot twice" alters/debatably replaces Step 1 (Choose a unit) entirely.

Forget the specifics, that not what I was illustrating. The point was a rule can override some core elements whilst not ignoring *all* Core Rules. It illustrates what I wanted it to (but don't dwell on the strat-specific detail as that is very different and has its own threads).

MachinaMandala wrote:

In this case, we have:
Rule A) Core Rulebook: A unit who advances, falls back or is within 1" of an enemy unit may not be chosen to shoot.
Rule B) Core Rulebook: A unit may shoot once.
Rule C) Stratagem: This unit may be chosen to shoot.
Rule D) Stratagem: This unit may shoot twice.

There are two sets of contradictory rules here. A and C can be contradictory and B and D are directly contradictory (as there is no statement about overriding existing rules on either of them), so much so that they cannot exist within the same game state.

The unit may be chosen to shoot twice. That is what the stratagem says, therefore Rule C) and D) don't exist. Rule B) doesn't really exist either, because it simply assumes that you will not activate the same unit twice by saying "choose another unit".
It has to target the closest enemy unit for both 'activations', that's a restriction that doesn't remove the other restrictions.

Therefore:
The stratagem gives us permission to activate the unit a second time (even though that's normally forbidden by the core rules), but only if it targeted the closes enemy unit during it's first activation AND it limits the target options for the 2nd activation to the closest enemy unit (even though normally you might have other options).

If you can't activate it the first time around you won't be able to activate it a second time.
This also means that iif you use the stratagem on a unit and then decide not to shoot at the closest enemy unit, but some other target, you still used the stratagem, but you won't be able to benefit from it.


TL;DR: The stratagem doesn't say "may be chosen to shoot"+"shoot twice". You added a word.

If you cannot be chosen to shoor, yoi cannot be chosen to shoor twice, and the game throws a MostPlaytestedException. The stratagem isn't "choose (>=1?2:default)", it's "choose(2)"

nekooni wrote:
The unit may be chosen to shoot twice. That is what the stratagem says, therefore Rule C) and D) don't exist. Rule B) doesn't really exist either, because it simply assumes that you will not activate the same unit twice by saying "choose another unit".
It has to target the closest enemy unit for both 'activations', that's a restriction that doesn't remove the other restrictions.

Therefore:
The stratagem gives us permission to activate the unit a second time (even though that's normally forbidden by the core rules), but only if it targeted the closes enemy unit during it's first activation AND it limits the target options for the 2nd activation to the closest enemy unit (even though normally you might have other options).

If you can't activate it the first time around you won't be able to activate it a second time.
This also means that iif you use the stratagem on a unit and then decide not to shoot at the closest enemy unit, but some other target, you still used the stratagem, but you won't be able to benefit from it.


TL;DR: The stratagem doesn't say "may be chosen to shoot"+"shoot twice". You added a word.

You are very wrong on Rule B. Rule B exists as an implicit rule. It doesn't need to be stated until we include the ability to be chosen to shoot more than once into the game set.

The rule "The unit may be chosen to shoot twice" is the conjunctive rule of C^D. It is still contradictory to A and B as it is made up of elements contradictory to both those rules.

You are correct! A unit who has advanced or fallen back if chosen to shoot must shoot twice at the closest unit. I'm glad we agree finally and that you've seen the light.

There's nothing to state that the unit chosen must already be able to shoot to have this stratagem applied to it. Nor that they must be able to be chosen to shoot to benefit from it.

TL;DR: You accuse me of adding in a word when you add in a paragraph. But thanks for agreeing with me!

MachinaMandala wrote:

You are very wrong on Rule B. Rule B exists as an implicit rule.

I'm sorry, but isn't that exactly what I said? The rule does not exist in written form, but it is clear that there is such a limitation in the core rules. How am I "very wrong" on that then?

It doesn't need to be stated until we include the ability to be chosen to shoot more than once into the game set.

Of course it should be stated since otherwise we already have the ability to be chosen to shoot multiple times - without using any stratagem - and that's obviously not the intention of the core rules, is it?
But we do not need it to be stated since we're all aware that this "unwritten rule" has to exist.

The rule "The unit may be chosen to shoot twice" is the conjunctive rule of C^D. It is still contradictory to A and B as it is made up of elements contradictory to both those rules.

No, it isn't. The rule "the unit may be chosen to shoot twice" is the written rule. C and D are created by you by interpreting that rule, and while doing that you are changing the meaning. That is why I said earlier that even a translation from text to pseudocode is an interpretation that is prone to "translation errors".

You are correct! A unit who has advanced or fallen back if chosen to shoot must shoot twice at the closest unit.

I fail to see how you got there from what I've written, could you please explain the steps? I literally wrote what's pretty much the opposite of that:
"It (the unit affected by the stratagem) has to target the closest enemy unit for both 'activations', that's a restriction that doesn't remove the other restrictions. "

I'm glad we agree finally and that you've seen the light.

I do not think we agree on this, at least not if your position is that the Stratagem overrides any and all restrictions that would normally apply and replaces them with a mere "must shoot the nearest unit", ignoring e.g. Rapid Fire weapons after an advance.
I also fail to see why you'd say "finally" when this was the first instance of me actually giving a position on the topic.

There's nothing to state that the unit chosen must already be able to shoot to have this stratagem applied to it. Nor that they must be able to be chosen to shoot to benefit from it.

That's absolutely correct. But it's a waste of CP because it won't actually do anything.
*edit* to add an example to clarify what I'm saying:

A unit with Assault weapons that advanced can be selected to shoot*. Models with an Assault weapon can then shoot those at -1 tohit. The stratagem allows the unit to do it twice, but it's still at -1 tohit each time.
A unit with Rapid Fire weapons that advanced cannot be selected to shoot. Even if you introduce the Stratagem and then interpret it so that the unit can be selected to shoot, no model in that unit has an Assault Weapon, and therefore no model will be able to fire a weapon, unless there's a different rule (e.g. Tallarn regimental doctrine) that lifts that restriction.

* = this is technically not RAW, but required to make Assault Weapons work while advancing. It doesn't change the outcome here however, so just roll with it.

You accuse me of adding in a word when you add in a paragraph.

Where exactly did I add a paragraph to a rule? I don't get it.


On a more general note: Can we please return to following Rule 1?

nekooni wrote:
I'm sorry, but isn't that exactly what I said? The rule does not exist in written form, but it is clear that there is such a limitation in the core rules. How am I "very wrong" on that then?

Of course it should be stated since otherwise we already have the ability to be chosen to shoot multiple times - without using any stratagem - and that's obviously not the intention of the core rules, is it?
But we do not need it to be stated since we're all aware that this "unwritten rule" has to exist.

You're contradicting yourself. You say that the rule B doesn't exist but then admit that it's implicit in the ruleset and then say that it's an unwritten rule.

Is it a rule? Is it not a rule? You need to decide on an argument before saying that I'm wrong.

nekooni wrote:
No, it isn't. The rule "the unit may be chosen to shoot twice" is the written rule. C and D are created by you by interpreting that rule, and while doing that you are changing the meaning. That is why I said earlier that even a translation from text to pseudocode is an interpretation that is prone to "translation errors".

Wrong again!

C and D are atomic rules created from the decomposition of the rule E. This is how boolean logic works. It was to illustrate a point, which is that the atomic rules of E are contradictory to the atomic rules of the core rulebook... Which they are.

nekooni wrote:
I fail to see how you got there from what I've written, could you please explain the steps? I literally wrote what's pretty much the opposite of that:
"It (the unit affected by the stratagem) has to target the closest enemy unit for both 'activations', that's a restriction that doesn't remove the other restrictions. "

You didn't write the opposite of that. You pointed out that the unit the stratagem is used on may be used to shoot twice at the closest enemy unit. In the case of units that have advanced or fallen back, that is the only choice they have.

Good job that you caught it so quickly.

nekooni wrote:

There's nothing to state that the unit chosen must already be able to shoot to have this stratagem applied to it. Nor that they must be able to be chosen to shoot to benefit from it.

That's absolutely correct. But it's a waste of CP because it won't actually do anything.
<snip> Where exactly did I add a paragraph to a rule? I don't get it.

You've added in the paragraph (illustrated before the snip) that:

"The unit must already be able to be chosen to shoot even before this stratagem is used, otherwise the stratagem is wasted. The ability to be chosen to shoot twice ignores usual shoot once restrictions."

It doesn't state anything along these lines in the stratagem. You've added it in to your mind in an attempt to justify what you feel the stratagem should do.

I'm pretty sure even RAI it's meant to work like I think it should anyway, so I don't really get the argument.

Dosnt "may" mean that it can happen, so if all the rules are satisfid that it may shoot twice, i dont see anything that forces anything to happen, because every thing after "may" is just a possibilty that could happen whislt following the core rules