First strike units not firing first?
-
Hello!
Perhaps I'm misunderstanding how first strike is supposed to work, but if not, I'm very confused by the behavior I'm seeing.
I have an attacker with regular units and a defender with some first strike and some regular units. I'm see the step order as:
attacker fire
defender fire first strike
defender fireWhich seems... wrong? Shouldn't first strike fire before attacker fires? If not, what's the point of first strike?
Here's the set up for the two unit types:
<attachment name="unitAttachment" attachTo="army" javaClass="UnitAttachment" type="unitType"> <option name="movement" value="1"/> <option name="transportCost" value="1"/> <option name="attack" value="2"/> <option name="defense" value="2"/> </attachment> <attachment name="unitAttachment" attachTo="fortified_army_first_strike" javaClass="UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="isFirstStrike" value="true"/> <option name="attack" value="0"/> <option name="defense" value="2"/> </attachment>
-
@myrd You are correct in your knowledge of the rules: in all cases in which offending units with "destroyer" are not present, defending units with "first strike" should roll to hit before offending units without "first strike" can do the same, and their casualties should also be removed from the game before such offending units can roll to hit.
If verified, this would be a major problem: please report it.
-
Interesting, the codebase has a test for the current behavior that we think is buggy.
If I print the steps for the test
defendingFirstStrikeBasic
, they are:[mockAttacker fire, mockDefender select casualties, mockDefender notify casualties, mockDefender first strike units fire, mockAttacker select first strike units casualties, mockAttacker notify first strike units casualties, Remove casualties]
@Trevan who authored that code and @LaFayette who reviewed that change (https://github.com/triplea-game/triplea/pull/6549) - do you have more context?
-
@myrd To add further information, in case it may be useful, in v2 rules games, the "strike" order is the same even with units with "destroyer", but such units elide the "remove first strike casualties" for all casualties of their same side (so that they are removed at the same time as normally hit units), whereas, in v3+ rules games, all units with "first strike" of a side count as not having this ability so long as the opposite side has at least one unit with "destroyer". In v1 there are no units with "destroyer", so one may either extend v2 rules to it too or have it working by v3+ rules if not having the "destroyer" ability ineffective (like if always false) under v1 rules.
It would be good if @Panther verifies all I said.
-
There's an option that controls this behavior - DEFENDING_SUBS_SNEAK_ATTACK (or "Defending Subs Sneak Attack" in the config file). If that option is false, then the defenders will always fire after the attackers, even with first strike. If the option is true, then the defenders will fire before the attackers. Most likely, the game you are playing has it set to false.
My change just refactored the code and the tests that I added were validating that I didn't break the existing functionality. I think https://github.com/triplea-game/triplea/commit/f0ef53104314c979426845d133316263b9ec6bc3 and https://github.com/triplea-game/triplea/commit/92cca6a64852983f7b308351df04091b7722d0a7 is when the original logic was added.
-
Thanks, that explains it - and I confirm that setting the property to true makes it work the way I expect.
Yuck about the set up, though. The global property is such a hack.
Ideally we could have the flexibility to have full control over the different permutations on a per-unit-type basis.
So in this case, this property wants to say that a given unit (sub) only does first strike on attack. So you'd want something like (in a hypothetical XML syntax):
<attack strength="2" diceSides="6" isFirstStrike="true"/> <defense strength="1" diceSides="6" isFirstStrike="false"/>
In an ideal set up, you would be able to also have units be able to do both a regular and a first strike attack (so perhaps can specify
<attack>
twice or have<firstStrikeAttack>
in addition to<attack>
or some other syntax).Then, the DEFENDING_SUBS_SNEAK_ATTACK property could be deprecated (and existing maps updated when the new engine is out to set the properties on the units instead).
-
@trevan Right ("Submarines" sneak attack only when offending in v1 only.), but, in that case, there would be a problem too. When that option is false, there should simply not be a "Blue first strike units fire" step at all when blue is defending. Since there was the step, I assumed the game was v2+ rules, since in v1 there are simply no defending units with "first strike" at all.
Also, this option should be automatically set true when the rules are v2 (actually, every rules set from v2 onwards).
-
@myrd said in First strike units not firing first?:
Ideally we could have the flexibility to have full control over the different permutations on a per-unit-type basis.
I strongly support this. That property can then be kept but deprecated.
-
@cernel To clarify, in v1 submarines should indeed fire separately from other defending units if there are offending air units but together if there are no offending air units. Anyway, the separate step in which only defending submarines fire should not be called as "first strike" or anything like that.
I defer to @Panther for confirmation.