Custom Firing Groups for units
-
I'm thinking of adding a mechanism to allow defining custom firing groups for units in a unified manner. Right now, this can be done with AA combat using
targetsAA
. For non-AA combat,canNotTarget
andcanNotBeTargetedBy
does most of it.I had mentioned this before at https://forums.triplea-game.org/topic/2302/non-aa-target-groups-names and recently saw https://forums.triplea-game.org/topic/2344/cannottarget-cannotbetargetedby-on-attack-defense which made me thing about this again.
Here's what I propose the XML to look like. The firing groups would be defined like:
<firingGroups> <firingGroup name="subs" display="Subs" canNotTarget="true"> <target value="fighter:bomber" /> <target value="battleship" unless="destroyer" /> </firingGroup> <firingGroup name="sub_to_air" display="Sub to Air Defense"> <target value="bomber" /> <target value="fighter" unless="battleship" /> </firingGroup> </firingGroups>
That creates two firing groups. One named "subs" where the units would NOT be able to hit fighters or bombers and only be able to hit battleships if a destroyer is present. The other is named "sub_to_air" where the units would be able to hit bombers but not fighters unless a battleship is present.
Then, to use the firing group, you would add
firingGroup
,firingGroupOffensive
,firingGroupDefensive
,firingGroupAA
,firingGroupAAOffensive
, and/orfiringGroupAADefensive
. Here's an example:<attachment name="unitAttachment" attachTo="submarine" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="isSub" value="true"/> <option name="movement" value="2"/> <option name="isSea" value="true"/> <option name="attack" value="2"/> <option name="defense" value="1"/> <option name="blockade" value="2"/> <option name="firingGroup" value="subs" /> <option name="firingGroupDefensive" value="sub_to_air" /> </attachment>
The
firingGroup
andfiringGroupAA
would be in effect in both offensive and defensive combat. It would be combined with any settings in theOffensive
orDefensive
versions.Is the XML acceptable? Is there some other things that I should include?
-
@Trevan seems a good addition. One will still be able to use the "targetsAA" with it ? I use it for special attacks on selective units before regular combat where it would attack normally also. Or does this replace "targetsAA" and you can then still do normal attack ?
Sidenote did the message format change due to the hack ? It looks different is all
-
@beelee It would basically replace
targetsAA
. Using an example from iron war, instead of writing<attachment name="unitAttachment" attachTo="Tank-Destroyer" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> ... <option name="typeAA" value="anti-vehicle gun"/> <option name="targetsAA" value="Mech-Inf:SP-Artillery:Light-Tank:Medium-Tank:Heavy-Tank:SS-Panzer:Tank-Destroyer"/> ... </attachment>
you could write
<firingGroups> <firingGroup name="anti-vehicle gun" display="Anti-Vehicle Gun"> <target value="Mech-Inf:SP-Artillery:Light-Tank:Medium-Tank:Heavy-Tank:SS-Panzer:Tank-Destroyer" /> </firingGroup> </firingGroups> ... <attachment name="unitAttachment" attachTo="Tank-Destroyer" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> ... <option name="firingGroupAA" value="anti-vehicle gun"/> ... </attachment>
The two would have identical behavior.
-
The original sub/air logic use unit properties to find the units that it can and can not target. So, I'm thinking of extending the xml so that you can create firing groups by units and by unit properties.
Here's how a sub would be defined:
<firingGroups> <firingGroup name="sub" display="Sub" canNotTarget="true"> <targetProperty value="isAir" /> </firingGroup> ... <attachment name="unitAttachment" attachTo="submarine" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> ... <option name="firingGroup" value="sub"/> ... </attachment>
And here is how air units would be defined:
<firingGroups> <firingGroup name="air_vs_sub" display="Air vs Naval" canNotTarget="true"> <targetProperty value="canEvade" unlessProperty="isDestroyer" /> </firingGroup> ... <attachment name="unitAttachment" attachTo="fighter" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> ... <option name="firingGroup" value="air_vs_sub"/> ... </attachment> ... <attachment name="unitAttachment" attachTo="bomber" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> ... <option name="firingGroup" value="air_vs_sub"/> ... </attachment>
Only boolean properties (true/false) would be allowed. Currently, I'm thinking it would only check if it is true but maybe it should have a way to negate the check.
-
A couple of thoughts.
targetProperty
feels like magic, and not really in line with my interpretation of @LaFayette's vision of an xml with less hacks. Also, it's kind of arbitrary, and variables can do more or less the same thing. I suggest that we expand variable functionality instead if the current one isn't enough.unless
isn't completely clear. Does it check for allied or enemy presence? In either case, why not have separate attributes for both? Quick plausible example:
<firingGroup name="charge" display="Cavalry Charge"> <target value="swordsman" unlessAllied="fortress" unlessEnemy="fortress:pikeman"/> </firingGroup>
- I'm not sure if there's an easy way to use both enabling and limiting (
canNotTarget
true and false) conditions for the same unit, but then I'm not sure if anyone would want to do that. Can anyone come up with a reasonable application where this would be necessary? - This can even be used to specify custom order of losses... well, sort of. Only if you don't mind having to wait a battle round to proceed to the next target, I guess.
<firingGroup name="atgun" display="Anti-Tank Gun"> <target value="tank"/> <target value="infantry:artillery:otherStuff" unlessEnemy="tank"/> </firingGroup>
Overall, I really, really like the direction where this is going. It takes multiple different mechanics, and unifies them into a greater, more flexible and at the same time much cleaner system. I never expected my 2014 wishlist on the old forum to become reality, but whenever I see new additions like this I feel that slowly, feature by feature, we're getting there - and beyond.
-
@alkexr Good point on the
unless
.Can you give me an example of how the variables would do that? I don't have much experience with writing map xml. I'm coming from this more from the Java code side and I'm trying to unify the logic in building out the firing groups.
-
<variableList> <variable name="AIR_UNITS"> <element name="fighter"/> <element name="bomber"/> <element name="etc."/> </variable> </variableList>
<firingGroup name="sub" display="Sub" canNotTarget="true"> <target value="$AIR_UNITS$" /> </firingGroup>
The engine will just replace all instances of
$AIR_UNTIS$
withfighter:bomber:etc.
, as plain text, before parsing the xml. This has the advantage that you can easily define any list, not just ones based on a single property. The disadvantage is that it won't react if you changeisAir
property of a unit with a trigger (but that probably isn't something you should be doing anyway). -
@alkexr said in Custom Firing Groups for units:
<firingGroup name="sub" display="Sub" canNotTarget="true">
<target value="$AIR_UNITS$" />
</firingGroup>I'll want to spend some more time thinking about this proposal, kinda interesting!
For variables, I think it might be easier all round to natively reference the list instead of an implicit inline. EG:
<firingGroup name="sub" display="Sub" canNotTarget="true"> <target unitList="AIR_UNITS" /> </firingGroup>