Civil War | Units Issues
-
@mattbarnes Issues wise, the main one should not have any major problems anymore, if ever. No idea about the small one, but I recall complaints. For gameplay, you'll have to wait for someone else, because I tried for half a round but gave up.
-
@Cernel Thanks. If it's not too great a breach of etiquette, could you please recommend other preferred maps? In addition to the ones above, I've also played Dragon War, Red Sun and Star Wars.
-
@mattbarnes Yes, the full size is very playable and fairly well balanced. The smaller (kind of test map) has some issues but you can still use it to learn the game. The rules are very unique and complex so takes some time to learn for most players.
Here are a few example games you might want to take a look at:
https://forums.triplea-game.org/topic/592/civil-war-3-2-4-redrum-confederate-vs-wirkey-union
https://forums.triplea-game.org/topic/879/civil-war-3-2-4-redrum-confederate-vs-wirkey-union-2
https://forums.triplea-game.org/topic/897/civil-war-3-2-4-wirkey-confederate-vs-redrum-union
https://forums.triplea-game.org/topic/962/civil-war-3-2-6-panzer-confederate-vs-redrum-union -
@redrum Cool, thanks.
-
Is Upperville broken, with no movement connections (in Eastern Campaigns)?
Also, why can't Confederates buy resources in first purchase phase? -
@redrum Hey, thanks for the example games. I looked at them all. Is it fair to say that the South won 3 games, in each case through a naval dominance strategy? I was expecting instead for the South to generally be on the back foot but win a fair share of games by holding out to hit one of their victory conditions. It was surprising to see them actually seem to be winning.
Incidentally, the resource purchase pop-up and/or the Game Notes could make clearer that the box has multiple tabs: it took me ages to spot how to buy resources: it looks at first as though only a handful of military units can be bought.
PS Happy Easter all, hope you're well and coping with lockdown.
-
@mattbarnes I know there are some missing connections in Eastern Campaigns though not sure anyone has ever written them down so we could fix them.
Well, I think the example games show that navy is very important and that the south can choose to compete at least for a while depending on what the north focuses on. Also I believe the north won 2 of those games and the south won 2 of those games (the side I played won all 4). There are a lot of viable strategies due to the asymmetric victory conditions and I do believe people conceded a bit too early in some of those games.
-
@redrum said in Civil War | Units Issues:
(the side I played won all 4)
Were the brackets meant to convey that you were whispering this under your breath? Like in a cough or a sneeze?
-
@Hepps That was just in case anyone else that happened to play Civil War against me wanted to post their game as well
-
@pulicat Discussing with @wirkey, it appears that the "Civil War: A House Divided" game, at least at version 3.2.6, has some more units issues, revolving mostly around the combat abilities of infrastructures. For your information, I don't play this map.
First of all, and this is generally a problem with the TripleA program (so, it can be cleanly fixed only at the engine level (thence this is mostly just a notification, even though some clarifications on the matter would be good to be made available in Notes to users)), any AA infrastructure should fire also if alone, before possibly getting captured, thus getting captured only if at least one attacking unit survives any first combat round fire. This is because, by intended rules, the conquest (or liberation) of the territory (thus the capture of every enemy infrastructure in the territory, as well) happens in a combat round step that is subsequent to the moment in which the AA (targeted) fire happens (it has actually nothing to do with the fact that the fire is AA-like, since the conquering step is also after any other kind of fire (as long as, of course, the infrastructure in question remains in the battle until the point in which it fires, but it is returned to the territory before the conquering step)).
In the basic games, the only situation in which this problem actually emerges is when (in V1.III and V3 all the same) a para-trooped infantry attacks a territory defended only by one AA Gun (there may be more than one AA Gun in the territory, since only one will defend). This problem is tracked here:
https://github.com/triplea-game/triplea/issues/5834For this game, instead, at least as far as the current behaviour of the program goes, the matter is relevant only for the "entrenchments" and the "fortifications" units, when owned by a player enemy of the turn player, in a territory not defended by any combat units (by combat units, I mean every unit that can take part in battles and can take at least one hit upon itself) that is being attacked by one or more units at which they can shoot.
For example, if you directly move only 1 infantry into an enemy territory occupied only by an enemy "entrenchments" unit (and no other enemy units):
- What happens is that the territory and the entrenchments are, respectively, conquered (or liberated) and captured (downgraded to breastwork (from now on, I will ignore the downgrade behaviour, as it is irrelevant to the matter at hand)) immediately as the infantry enters the territory, during the Combat Move phase, without any fire from the entrenchments.
- What should happen, instead, is that nothing else happens during the Combat Move phase, then, during the Conduct Combat phase, a battle in the zone is generated (with the infantry as the attacker and the entrenchments as the defender), during which the entrenchments fires 1 targeted (AA) shot (a "cannonade") at the infantry, then the territory is conquered only if this shot misses (if the shot hits, the infantry is removed before being able to conquer the territory).
In the same example, if you would have sent 2 infantries, instead of only 1, and you are playing under "Low Luck" rules, the territory will be conquered for sure, because at least 1 infantry will survive. Still, the difference between the correct and the program's behaviour is that the entrenchments at least should get to shoot its "cannonades" before being (inevitably, in this case) captured.
However, since this game allows blitzing through "capturable" units ("infrastructures", as identified in the game file) (amongst the basic games, only "v1" has this behaviour (any unit (comprising factories) blocks blitz from "v2" onwards, instead)), the current behaviour is correct in case of blitzing, because, only when blitzing, territory ownership (and infrastructure ownership) changes during Combat Move, for every territory you are moving through, which is how the program (always) behaves (and, for blitzed territories, it is actually a correct behaviour).
For example, if you have a territory with an "entrenchments" only in it and an enemy "cavalry" enters the territory and, then, immediately enters another territory (this is a "blitzing" move) (this other territory can also be the same territory whence the unit started its movement), what should happen and what happens is that the territory and the entrenchments are, respectively, conquered and captured during Combat Move, without any fire from the entrenchments.
However, if the rules would apply correctly (which they don't) this would cause a realistically absurd situation, by which, if a cavalry in an owned territory simply moves and ends its movement into an enemy territory that contains only an entrenchments, it gets fired at (it actually doesn't, because the current program behaviour is wrong), and possibly removed before being able to conquer the territory and capture the entrenchment, while, if the same cavalry, after having entered the enemy territory, immediately thereafter moves into an other territory or back to the initial territory, then the entrenchments would be captured without any fire (because, in this case, the "blitzing" rules would apply, causing the territory to change ownership during the Combat Move phase).
What detailed above would not be itself a problem, but, especially for a game that aims at realism, I find realistically nonsensical that a lone infrastructure would be taken without a fight if blitzing the territory, but, instead, taken only after it has fired if the same territory is attacked (maybe by a cavalry that could have blitzed it (meaning that the cavalry ended its movement into it after using only half of its mobility (thus not technically blitzing, since it didn't exit the invaded territory, even though it could have had))). A way this nonsense might be avoided is by giving the "entrenchments", as well as "fortifications", a fly-over (fly-over in name only, as it would be against land units passing through) ability against the same targets as the targets of its "cannonades" fire, so that it may, this way, hit any "cavalry" and "elite_cavalry" that is blitzing the territory, if we assume that the "fly-over" rules apply to any unit moving through (no matter if air). However, this would raise the issue whether or not a cavalry blitzing through a territory with an entrenchments alone, having a fly-over shot against the cavalry, would fail to conquer the territory if hit by this fly over (this would assume that the fly-over shot happens before the unit conquers the territory by blitzing). In my opinion, the closest adaptation of the rules would imply that, due to everything being simultaneous if not differently specified, the cavalry gets shot by the entrenchments as it overtakes both the territory and the entrenchments. So, on this account, even if the entrenchments would successfully shot the cavalry, the territory would still be conquered, therefore the entrenchment still captured, at the same moment in which the cavalry is removed from the game. However, I'm far from sure about this, as it seems to me to be very strange that a unit may conquer a territory and capture an other unit while it is being removed from play by the unit it is capturing (still talking about the intended rules, not the program's behaviour). It seems also very inconsistent with how the targeted shots should work in regular combat (thus would not really solve the issue for which we would add the fly-over shots in the first place), as, if the elimination of all attacking units by such shots avoids the conquest of the territory, then it would really make the only sense that also a blitzing conquest of a territory is averted if all the blitzing units are shot down by fly-overs. Of course, the first step, in this case, would be testing how the program currently behaves in any such matters (I have not tested fly-over fire against land units).
All said up to this point, while making the case for the "entrenchments" unit, applies to the "fortifications" unit as well (it applies to any land infrastructures able to do targeted (AA) fire against one or more land units).
The conclusion is that, in my opinion, to upkeep realism while pursuing rules compliance, if the "entrenchments" and "fortifications" are made non-capturable during Combat Move if the territory is not being blitzed and are also made able to fire during the first round of combat no matter if alone (as they should, if this game is supposed actually to follow any basic rules set), then (assuming the behaviour of infrastructures never blocking anything is to be kept) it would be opportune adding to them a fly-over ability against blitzing units, with the same fire power and eligible targets as the "cannonades" fire (as well as a random selection of targets (to assure this, it would be needed also to fix the problem related to fly-overs, especially the fact that the fire resolution should be at the end of the phase, not immediately after making the fly-over move, during the phase)), and following the rule that any blitzing unit shot down by such fly-overs will fail to capture the territory where such fire happened. Of course, as per normal fly-over rules, these movements should be first all plotted, then resolved only after all combat movements have been done or plotted (the actual moment in which to resolve them should probably better follow basic v2 rules (which TripleA fails to follow properly, but this is yet another issue with the program), not LHTR, on the account that not all such units are necessarily blitzing to end their movement into a territory where a battle will be generated, on the same turn (if I understand correctly that, under v2 LHTR intended rules, every fly-over is to be resolved only immediately before the battle the flying-over unit is going to participate to, each time resolving only the ones for the same battle all together)).
Maybe the preferred solution, instead, may be to leave everything working as it currently does (but this would need documentation, as it would be turning a wrong program behaviour into a custom rule), about the universally instantaneous capture of infrastructures alone (as well as the necessarily concurrent conquest of empty territories or of territories occupied only by infrastructures without having to blitz them). If this would be preferred, however, I suppose it should be properly done by adding a custom property, for such a behaviour, to the program, then updating the game file, adding the property (as said, currently the behaviour, instead, wanted or not, merely relies on a faulty application of basic rules (likely, in turn, based on a faulty understanding of them by every developer that has been responsible for their implementation)).
An alternative approach may be to split "infrastructure" units between able and unable to block, having "entrenchments" and "fortifications" as the only land infrastructures able to block (as being the only ones able to fire). This would require changing the program, as currently the ability to define one or the other behaviour is generalized to all units, instead (either all infrastructures block blitz or they all don't).
However, while there are rules for "AA" infrastructures firing only before the first combat round, the matter is not that clear in the moment there are any such units firing before every combat round (as TripleA allows to and since this game uses such possibility). How basic AA infrastructures work is that they are (definitively) removed from the battle and returned to the zone of the battle immediately after they have done their AA fire. So, as far as the battle itself goes, AA infrastructures are behaviourally no different from suicide units being removed from the game immediately after having fired (the difference being that one is returned to the map and the other one is removed from the game, but this is irrelevant, as far as the battle goes). So, here the matter would be defining what are the intended rules for AA units that remain in the battle after having fired on the first combat round. If (and here I'm just assuming) the intended rules in question are that infrastructures are removed from the battle (and returned to the zone of the battle) only as soon as the units remaining on the same side are all infrastructures, then such a behaviour would appear to me to be self-inconsistent when you have AA fire happening before every combat round (as it is the case in this game) (but this would also apply to any infrastructure having any kind of non-AA fire capability, happening in the course of multiple combat rounds), because it implies that infrastructures alone can fire before the first combat round, but never on any other combat round. In my opinion, if it is possible having infrastructures alone firing before being possibly conquered, on the first combat round, then it would be consistent the most that this could happen on any combat round. Currently, this would be not possible, if the intended rules for infrastructures firing beyond the first combat round would be to remain in the battle as long as at least one non-infrastructure unit remain on the same side, because, this way, it can just never happen that infrastructures alone are defending on the second or any following combat rounds, since they would have been already removed from the battle, returned to the zone of the battle and captured. For this reason, I actually tend to think that the current engine behaviour is more generally consistent (still, this doesn't make it correct), thus would deserve to be kept as an optional behaviour. I'm thinking this means having a property that, if enabled, has infrastructures conquered immediately if alone (this would also apply to the case of paratroopers conquering territories defended only by AA guns), thus unable to use they fire capability in battle (which is the current behaviour). If such a property is made, this map could have it, if preferred, therefore keeping the current behaviour, but properly so (as a custom behaviour, instead of as a wrong behaviour).
Finally, also the "torpedo" is affected by this problem (being unable to make its "targeted" (AA) fire if alone), even though this is not as clearly determined based on the basic rules, as those rules refer to the "aaGun" units only, which can never be on the sea, but as cargo. However, as long as we expand the basic rules as to work the same way on land and sea, when "aaGun" like units are presented (and not as cargo), then the problem appears to be the same or analogue. Specifically, when one or more "torpedo" units are defending alone a zone owned by the same player, the zone is conquered and all torpedo inside it are captured (thus destroyed) without being able to make their "targeted" (AA) fire.
Moreover, since the "torpedo" is also able to make offensive "targeted" (AA) fire, the problem appears to be substantially the same on the offensive, in that any "torpedo" unit of the turn player is captured by the enemy, before being able to make its "torpedoes" fire, if it occupies a sea territory owned by the turn player that is occupied by enemy non-torpedo units and no non-torpedo units of the turn player.
CC: @Panther For anything for which I've referenced the basic rules sets.
"Torpedo" units, owned by a player, inside sea territories (in this game, sea zones are territories too (they are owned and capturable convoy zones with 0 PUs value)) owned by the opposite player or no player (meaning that no "Current Owner" is given in the "Territory" tab (I assume being owned by no player actually means being owned by the "Neutral" player, though the "Territory" tab doesn't actually specify that in any way)) and occupied by no other units of the player owning the torpedoes are not captured (that is not destroyed, as they are destroyed whenever captured) when one or more enemy units move through them nor when one or more enemy units end the Combat Move phase inside the sea zone (this is a potential problem, that land infrastructures don't appear presenting), during the turn of the owner of the enemy units. Meaning that when one or more units owned by the turn player are inside the same zone as enemy torpedo units and no other enemy units, at the end of the Combat Move phase (usually because they moved into the zone during the phase), no battle is created nor the torpedoes are captured (that is, destroyed) in any way if the sea territory is (and was, since start turn) owned by the turn player or by no player (the units of the turn player just remain in the sea territory with the enemy torpedo units, the sea territory remaining owned by the turn player or unowned and the torpedo units remaining enemy owned). This problem doesn't appear to be present for "torpedo" units that are in sea territories owned by the same player owning such units (meaning that enemy "torpedo" units in enemy, non-Neutral, sea territories are immediately destroyed on capture by any unit entering, thus capturing, the sea territory (which is not a correct behaviour, at least if the unit is ending its movement in there, as the territory should not be conquered during Combat Move and a battle should be generated during Conduct Combat (during which the territory may be conquered), but this is an other problem)).
The problem appears at least in part immediately related to the problem that sea territories that are unowned (thus, assumingly, owned by the "Neutral" (null) player (the factual "Neutral" (null) ownership of every sea territory that is not otherwise owned can be seen when any one of them is captured, as the history will say "from Neutral", even though the ownership is completely missing in the "Territory" tab (there is no mention of "Neutral" being the current or original, or both, owner, in the tab)) (all sea zones are territories that start without any ownership assigned in the game file (they are all absent in the owner initialize))) can be conquered by any player during the player's turn only by winning a battle in it (this is almost surely a wrong program behaviour, as unowned sea territories should be conquered just like sea territories owned by an enemy player, especially since this appears to be the behaviour for land territories). Whatever the intentions and how the engine handles the matter, the behaviour for sea territories having no current owner in the "Territory" tab (that is all sea territories at start game) is that they are captured only after having resolved a battle in it, by whoever won the battle, or by occupying them with any sea units other than "torpedo" and "transport", during the "Battle" phase of the opposing player (this implies that, during the first round of the game, all non-owned (thus assumingly "Neutral" (null) player owned) sea territories occupied only by Union sea units other than "transport" are conquered by the Union during the "Battle" phase of Confederate, then all non-owned (thus assumingly "Neutral" (null) player owned) sea territories occupied only by Confederate sea units other than "transport" are conquered by the Confederate during the "Battle" phase of Union).
This means that "torpedo" alone in a sea zone not owned by the same owner of the torpedoes have the (basic rules wise) double problem of not creating a battle at all (this is a problem common to all infrastructures, when alone) and not being captured (thus destroyed) (this other problem appears to matter only for sea territories, not land ones, as infrastructures in land territories should always belong to the same owner as the territory they are occupying), when one or more enemy units are in, or move through, the same zone, during the turn of the owner of the enemy units.
On this matter, the notes say that "Torpedo fields are either cleared after combat, or in the case of empty torpedo fields devoid of enemy units, cleared at the beginning of enemy combat move phase", but this is an unclear and non-precise explanation of the actual program behaviour (but this is another problem) and, anyway, whatever that means, all these behaviours are most likely things that the program enforces without following a clear and coherent dynamic (for example, I'm not seeing how being unable to conquer unowned and unoccupied sea zones during your turn can be not a wrong behaviour, and it seems to me especially absurd that you can do it during the turn of your enemy but not during your own turn) (I think it would make the most sense being able to capture enemy infrastructures also if they are in non-enemy territories or in non-territorial zones) and I believe it is not good just to (maybe fatalistically) accept arguably wrong program behaviours. I rather suggest investigating and at least sorting out how such matters should actually correctly behave, based on the basic rules, or decide how it would be preferred them behaving, for the game at hand, then documenting the intended and wanted behaviours for the game, then documenting the discrepancies with the current behaviour in the "House rules unsupported by engine" section of notes, waiting for a developer to fix, or anyway change, the engine.
In sea territories where there are only torpedo units of one side against only torpedo units of the other side, nothing ever happens (no matter the ownership of the sea territory, or absence thereof), but the notes are not documenting this behaviour.
I think this is the correct behaviour, and I suppose it is fairly obvious that torpedoes-only should ignore each other completely, but I believe it would be good to make the matter clear in the notes (clarifying that "torpedo" units can never conquer sea territories nor "clear" enemy torpedoes).
During any (and especially the first) "Confederate" "Battle" phase, all unowned sea territories occupied by "Union" owned sea units, other than "torpedo" and "transport", are conquered by the "Union" (clearly an effect of the "Abandoned Territories May Be Taken Over Immediately" property). Similarly, during any (and especially the first) "Union" "Battle" phase, all unowned sea territories occupied by "Confederate" owned sea units, other than "torpedo" and "transport", are conquered by the "Confederate" (clearly an effect of the "Abandoned Territories May Be Taken Over Immediately" property). This is an example of what is recorded in history, during the first turn of Confederate: "Confederate has abandoned Delaware Mouth SZ to Union: Union takes Delaware Mouth SZ from Neutral" (this communication doesn't actually make sense, as the sea territory is owned by "Neutral" and it has never been owned by "Confederate", nor "Confederate" ever had any units in it).
Hard to say to which extent this behaviour is wanted or advantageous, but it has the considerable effect of cluttering history (and causing cacophonies) with a number of "abandoned" events that are merely unowned and unproductive sea territories being conquered by the player enemy to the turn player (accrued by the fact that, wherever only transports are in a sea territory, history will have the "has abandoned" notification, but nothing happens, since transports cannot conquer sea territories (I tend to see this as a disconnect in the program process, in that I tend to think the program should not say anything if it is inconsequential, as the territory is arguably not really abandoned if the enemy units cannot overtake it)).
My guess is that assigning every sea zone a territory, all of them having 0 production value and no particular use, without giving any such territory a starting (thus original) ownership, is some sort of workaround to implement some wanted behaviour (I suppose at least related to the destructive capture of "torpedo" units). If so, this would better to be clarified and documented, to start with, then considering if all such matters can be achieved in a better, or at least cleaner, way, possibly by opening a feature request about it (if not a problem report).
This is how "cannonades" are explained to work, in notes:
Cannonades: This game introduces the idea of cannonades, which represents bombardment from afar. Cannonade mechanics work similar to aaGuns in that they occur before regular combat and casualties are removed from battle. Note that artillery has both a cannonade ability (shooting shells from afar) and regular attack and defence values (firing grapeshot at close range), meaning artillery units fire in both the cannonade and regular combat sequences.
Combat Sequence in Detail
Attacker artillery cannonade (when applicable): Attacker's artillery fires a long-distance bombardment, rolling at 1/12 against each eligible enemy defender. These casualties are removed from battle and do not participate in further combat.
Defender artillery cannonade (when applicable): Defender's artillery fires a long-distance bombardment, rolling at 1/12 against each eligible enemy attacker. These casualties are removed from battle and do not participate in further combat.
Defender entrenchment and fortification cannonades (when applicable): Defender's fieldworks fire long-distance bombardments, rolling at 1/12 (for entrenchments) or 2/12 (for fortifications) against each eligible enemy attacker. These casualties are removed from battle and do not participate in further combat.
Attacker fire: Attacking units close in for combat. These casualties return fire.
Defender fire: Defending units return close-combat. These casualties are removed from battle.
End of combat round: At the end of the first combat round, attacker has the choice to retreat or stay for the second round. At the second combat round, stalemate is reached if both sides still have troops remaining.The "entrenchments" is documented on the map as having the ability "cannonades at 1" and in notes as "cannonade rolls against up to 12 attackers @1". The "fortifications" is documented on the map as having the ability "cannonades at 2" and in notes as "cannonade rolls against up to 12 attackers @2". Only in notes, there is for all combat units the property "fieldwork cannonade target". Only in notes, there is for all combat units, but "cavalry" and "elite_cavalry", the property "artillery cannonade target".
No more information is given.
Thus, it is not stated anywhere in the legend on the map nor in notes whether "entrenchments" and "fortifications" cannonades cumulate or not with each other (meaning whether or not a same unit can be targeted by both on the same combat round). Since the notes say something like "cannonade rolls against up to 12 attackers @1", which quite clearly implies that such 12 shots needs to be assigned to 12 different units to be fully used (similarly to how AA shots work in v5, albeit here assigned randomly), hence no single unit possibly getting more than 1 at the same time, and the targeted attack is specifically identified as "cannonade" in all such cases, it seems that the shot is the same type (the type being "cannonade") for every unit having such a targeted fire identified exactly as "cannonade". Thus such "entrenchments" and "fortifications" cannonades would be the same type of targeted fire, hence never cumulative (meaning that the same unit should not be able to be targeted by any more than one of them, during the same combat round). This is, in my opinion, reinforced (if not confirmed) both by the fact that the targets are identified by the "fieldwork cannonade target" property (and not by two properties, each referring to one or the other type of units) and by the fact that, in the combat sequence, "entrenchments" and "fortifications" are grouped together in the same step. Alternatively, if one would interpret anything like "cannonade rolls against up to 12 attackers @1" as referring to the single unit, then "entrenchments" and "fortifications" should be able to make 1 cannonade each (at 1 and 2, respectively) on each of 12 enemy units, but, in this case, two "artillery" units should be able to make 1 cannonade each on each of 12 enemy units, as well (of course, knowing TripleA, this alternative interpretation is simply not possible, but this cannot be known to any user).
Moreover, if "entrenchments" and "fortifications" are supposed not to be able to hit the same target during the same combat round, how priorities are defined should be clarified (since one hits at 1 and the other one hits at 2).
However, my interpretation of the rules in question is not how the game actually works, nor how it is supposed to work according to the coding in the game file. Also my alternative interpretation does not correspond to the game's behaviour. How it works is that the same unit can be targeted by one cannonade of every type of units having the "cannonades" ability (meaning that, for example, while 2 artillery need 24 or more eligible targets to use all their cannonades, 1 entrenchments and 1 fortifications together can use all their cannonades against only 12 eligible targets, each target receiving two cannonades shots).
If my interpretation is correct, the notes should be clear about it (as now, it is more of a guess than an actual interpretation, in my opinion) and the game should be changed to work accordingly (if possible under the current engine, otherwise opening a feature request about it). Otherwise, if the current behaviour is correct on this regard, the notes should be changed as to inform the user correctly, fully and clearly.
These are the types for the targeted shots of any unit having such ability:
artillery:
<option name="typeAA" value="artillery_cannonade"/>torpedo:
<option name="typeAA" value="torpedoes"/>entrenchments:
<option name="typeAA" value="entrenchments_cannonade"/>fortifications:
<option name="typeAA" value="fortifications_cannonade"/>What I would have expected, instead, based on the notes, is to find the same type shared amongst the "entrenchments" and "fortifications" units, while "artillery" having a different type. Artillery having a different type would be due to being on a different step in the detailed combat sequence.
Instead, if it is intended that the same unit can be targeted by "entrenchments" and "fortifications" on the same combat round (as per the current game behaviour and code), this behaviour should be clearly documented in the notes (starting from splitting the "Defender entrenchment and fortification cannonades..." step of the "Combat Sequence in Detail" in two steps, one for "entrenchments" and the other one for "fortifications" or by clarifying that the same unit can be hit by up to one of both during the same step).
This issue is arguably tempered by the fact that the automatically generated tooltips will tell you the types of the "targeted" attacks and defences, thus showing the user that no such type is shared amongst different types of units (but I believe only very knowledgeable users will be able to deduct inter-type cumulability out of this).
This is the description for "torpedo", in notes:
*Torpedoes are naval mines, special defensive units that fire once before a battle and cannot be taken as casualties. Each torpedo rolls at 3 at one ship. To target more ships you need more torpedoes. Torpedo fields are either cleared after combat, or in the case of empty torpedo fields devoid of enemy units, cleared at the beginning of enemy combat move phase.
There are several problems with this description, namely:
- It is at best incomplete to define these units as "defensive units", because (from the game file coding) they appear to have on the offence the same combat abilities they have on the defence (if, by "defensive units", it is implied that they should be defence-only, then the game file coding is wrong).
- Saying that "Each torpedo rolls at 3 at one ship.", without any additional specification regarding the eligible targets, is not very clear, as nowhere in notes is explained what a "ship" is ("ship" is not the name of any units nor the name of any classes of units). Going with what I believe the common understanding of what a "ship" is in real life, I would understand it as any unit able to move over the sea (I guess this would include submarines too, since they are surely able to move over the sea, even though they are intended to move under its surface (but I'm far from sure whether or not a submarine should be considered a ship too, especially during the US American Secession War (the so-called Civil War))), which would imply that the eligible targets are all sea units having a mobility value of 1 or more, which would be "gunboat", "ironclad", "frigate", "battleship", "submarine" and "transport" (that is all sea units except "torpedo" and "pontoon bridge"). However, according to the game file, the eligible targets for "torpedoes" fire are "gunboat", "ironclad", "frigate", "battleship" and "transport" (that is all sea units except "submarine", "torpedo" and "pontoon bridge" (that is all mobile surface-only sea units)).
- Nothing in the description is (clearly, at least) explaining that you cannot target the same enemy ship with more than one "torpedo" (meaning that, according to the game's behaviour, you cannot roll more dice than the number of eligible targets, for the torpedo fire). I assume that this is likely meant to be covered by the "To target more ships you need more torpedoes" explanation following the "Each torpedo rolls at 3 at one ship" (this phrase doesn't literally exclude that two or more torpedoes may roll at the same ship) explanation, but, literally, other than communicating that the "torpedo" rolls at 3 (which is also documented in the unit information table), these two explanations are arguably hinting to the fact that you need to target specific units before assigning any hits to one or more of them, but are not literally excluding that two or more "torpedo" units can target the same unit, if wanted (which they actually cannot, according to the game's behaviour).
- In the "Torpedo fields are either cleared after combat" description, it is not clear when that (whatever that means) exactly happens, as "after combat" may be read either as "after every battle" or "after the Conduct Combat phase" and, in both cases, it is not clarified whether that would be immediately after or just sometime after (strictly speaking, "after" doesn't necessarily mean "immediately after", even though context here quite obviously implies that has to be the meaning (in this case, it would have been more precise to say "immediately after combat" or "as soon as combat is over", instead of only "after combat"). If, as I guess, "after combat" means "immediately after any battle (in a sea zone)", that should be made clearer (one might wonder if that means upon ending the phase during which you conduct combat, instead).
- Saying "Torpedo fields are either cleared after combat" doesn't clarify which "torpedo fields" are "cleared", at that point, thus can mean whatever torpedo unit on the map, thus possibly that all "torpedo" units on the map are removed from the game at the end of every battle or at the end of the "Battle" (Conduct Combat) phase (depending of what "after combat" means). If only the "torpedo" units in the zone of the battle (thus excluding "torpedo" units everywhere else on the map) are "cleared", that should be clarified (I realize it's pretty obvious, but that doesn't make it literally exact). If only the "torpedo" units owned by the player enemy of the player that won the battle are affected (fairly obvious, but not literally stated), that should be clarified (this can also happen because of the attacker retreating or when all units of one side submerge, giving the victory to the other side).
- Saying "empty torpedo fields devoid of enemy units" only vaguely tells that the reference is (or, at least, I assume it is) to "enemy torpedo fields in sea zones not occupied by any other enemy units" (as much obvious as it might be, the phrase is literally not telling that the torpedo fields are "enemy" too). In particular, the phrase might be read as the "enemy units" being enemies of the "torpedo" units, which would imply that the reference is to "torpedo fields" owned by a player in a zone not occupied by any unit of the opposite player (obviously, this cannot be the case, based on context).
- Saying "empty torpedo fields devoid of enemy units, [are] cleared at the beginning of enemy combat move phase" is unclear a wording, as it can (as intended, in my understanding) be read as the "enemy combat move phase" being the phase of the same player owning both the "enemy units" and the "torpedo" units (if we also assume that the "enemy units" are owned by the same player owning the torpedoes), or (but I'm almost sure this is not the intention) as the "enemy combat move phase" being the phase of the player enemy of the player owning the "torpedo fields".
- Saying "empty torpedo fields devoid of enemy units, [are] cleared at the beginning of enemy combat move phase", assuming that means "torpedo units, owned by a player, that are inside sea zones not occupied by any other units owned by the same player, are cleared at the beginning of the Combat Move phase of the player", is missing to clarify that, for what stated to happen, the player of whom the "torpedo" are enemy must have one or more units in each of the sea zones. Moreover, to be consistent with the game's behaviour, it would be also necessary to specify that this is excluding "torpedo" and "transport" units (which appears unable to "clear" enemy torpedoes).
- Saying "empty torpedo fields devoid of enemy units, [are] cleared at the beginning of enemy combat move phase", assuming that means "torpedo units, owned by a player, that are inside sea zones not occupied by any other units owned by the same player, are cleared at the beginning of the Combat Move phase of the player if one or more enemy units, other than "torpedo" and "transport", are in the zone", it is not actually how the game works, as this happens during the "Battle" (Conduct Combat) phase, not at the start of (or at any point during) the "Combat Move" phase (in fact, the player can move its own units into the zone, so to assure that its "torpedo fields" are not any longer "devoid of enemy units", avoiding them being "cleared" this way (a battle will be generated and they will be "cleared" only if the battle is lost to the turn player)).
- Saying "empty torpedo fields devoid of enemy units, [are] cleared at the beginning of enemy combat move phase", assuming that means "torpedo units, owned by a player, that are inside sea zones not occupied by any other units owned by the same player, are cleared at the beginning of the Combat Move phase of the player if one or more enemy units, other than "torpedo" and "transport", are in the zone", and overlooking the fact that anything like that happens during the "Battle" (Conduct Combat) phase only, is missing to specify that happens only as long as the sea zone is owned by the turn player on by no player (for example, if, at the start of the Union turn, a Confederate "battleship" in inside a sea zone otherwise occupied only by an Union "torpedo", the Union "torpedo" is removed from the game, during the "Battle" phase of Union, only if the sea zone is a sea territory owned by Union or by no player (the Union "torpedo" is not removed if the sea zone is a territory owned by Confederate, before the "Battle" phase, instead)) (if this last item is (as it most likely is) something working incorrectly, then the matter would be documenting it in the "House rules unsupported by engine" section (telling the users they should remove such "torpedo fields" with edit mode, if the program is not doing it)).
- The cases under which "empty torpedo fields devoid of enemy units" (if this actually means that the torpedo units are owned by the same player owning the "enemy units") are "cleared" are missing the case in which enemy "torpedo" units in enemy, non-Neutral, sea territories are immediately destroyed on capture by any unit entering or staying into (this second case would happen when the units were mobilized during the previous round), thus conquering, the sea territory (which is not a correct behaviour, at least if the unit is ending its movement in there, as the territory should not be conquered during Combat Move and a battle should be generated during Conduct Combat (during which the territory may be conquered), but this is an other problem). If this missing item is intended, meaning that "empty torpedo fields" are supposed never to be conquered this way, then the "House rules unsupported by engine" section of notes is missing to document it (the players would need at least editing the ownership of the torpedo back).
In any case the documented rules and the engine behaviour differ, and the rules are (assumed to be) not wrong, if the players are supposed to edit the behaviour according to the rules documented in notes, this should better be added to the "House rules unsupported by engine" section.
For the record, this is the attachment in question (from the game file):
<attachment name="unitAttachment" attachTo="torpedo" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="isSea" value="true"/> <option name="requiresUnits" value="shipyard"/> <option name="requiresUnits" value="engineers"/> <option name="isConstruction" value="true"/> <option name="constructionType" value="torpedo_structure"/> <option name="constructionsPerTerrPerTypePerTurn" value="3"/> <option name="maxConstructionsPerTypePerTerr" value="1000"/> <option name="destroyedWhenCapturedBy" value="FROM:Union:Confederate"/> <option name="destroyedWhenCapturedBy" value="FROM:Confederate:Union"/> <option name="destroyedWhenCapturedBy" value="FROM:Pro-Confederate:Union"/> <option name="destroyedWhenCapturedBy" value="FROM:Pro-Union:Confederate"/> <option name="isInfrastructure" value="true"/> <option name="unitPlacementRestrictions" value="Aberdeen Station:Allentown Station:Alton Station:Columbus Georgia Station:Andersen Station:Athens Station:Atlanta Station:Augusta Station:Baltimore Station:Berkley Springs Station:Blackville Station:Bloomington Junction Station:Branchville Station:Chambersburg Station:Champaign Station:Charleston Station:Cairo Station:Charlotte Station:Charlottesville Station:Chattanooga Station:Cheraw Station:Chester Station:Chicago Station:Chickamauga Station:Cincinnati Station:Cleveland Station:College Hill Station:Columbia Station:Columbus Station:Crawfords Station:Culpeper Station:Danville Station:Dayton Station:Decatur Station:Edwards Station Station:Evansville Station:Frankfort Station:Fredericksburg Station:Goldsboro Station:Gordonsville Station:Greensboro Station:Hanover Junction Station:Harpers Ferry Station:Harrisburg Station:Hillsboro Station:Huntington Station:Indianapolis Station:Iowa City Station:Jackson Station:Jonesboro Station:Jasper Station:Kaskaskia Station:Keaton Station:Kingston Station:Kittanning Station:Kokomo Station:La Grange Station:Leakesville Station:Lebanon Station:Lewistown Station:Louisville Station:Lynchburg Station:Macon Station:Manassas Station:Marietta Station:Maryville Station:Memphis Station:Meridian Station:Ogeechee Station:Mobile Station:Mechanicsville Station:Montgomery Station:Moulton Station:Murfreesboro Station:Naples Station:Nashville Station:New Market Station:New Orleans Station:New York Station:Newbern Station:Newton Station:Nottoway Station:Ottawa Station:Paris Station:Petersburg Station:Philadelphia Station:Corinth Station:Pittsburg Station:Port Hudson Station:Pulaski Station:Ravenna Station:Richmond Station:Ridgeway Station:Rock Island Station:Salem Station:Savannah Station:Shelbyville Station:Somerset Station:Springfield Station:St Louis Station:Strasburg Station:Suffolk Station:Milledgeville Station:Talladega Station:Toledo Station:Tuskegee Station:Union Church Station:Valparaiso Station:Vicksburg Station:Vincennes Station:Warsaw Station:Washington Station:Wilmington Station:Wooster Station:York Station:Zanesville Station:Munfordville Station:Brandon Station:Bowling Green Station"/> <option name="maxAAattacks" value="1"/> <option name="maxRoundsAA" value="1"/> <option name="attackAA" value="3"/> <option name="attackAAmaxDieSides" value="12"/> <option name="offensiveAttackAA" value="3"/> <option name="offensiveAttackAAmaxDieSides" value="12"/> <option name="isAAforCombatOnly" value="true"/> <option name="typeAA" value="torpedoes"/> <option name="damageableAA" value="true"/> <option name="targetsAA" value="gunboat:ironclad:frigate:battleship:transport"/> </attachment>
According to a literal reading of the "Combat Sequence in Detail" description, every defending artillery hit by cannonades should be unable to do its own cannonades (since the point in which defending cannonades are done is after the point in which casualties from attacking cannonades are removed from the battle) (this is why in the regular combat sequence defending casualties are not removed from the battle but after the step in which they fire).
However, the game behaviour is that defending artillery hit by cannonades can make its own cannonades, before being removed.
If this is a problem with the description, not with the game's behaviour, the description should be reworded.
This issue is tempered by the fact that, at least currently, targeted fire can never negate the fireback from other targeted fire able units. So, anyone having knowledge of the TripleA program on the matter and reading the automatically generated tooltips (thus verifying that the "cannonades" are a type of AA fire) will know that every unit selected as casualty from attacking "cannonades" fire will be able still to make its own defending "cannonades" fire if having such ability.
Nowhere in notes is explained that units hit by "torpedoes" fire are removed without firing back. I suppose this may be intended to be implicit in the "Torpedoes are naval mines, special defensive units that fire once before a battle" rule. However, firing before a battle (which is itself a strange way to define the matter, as normally all units involved in a battle are added to it before resolving any related combat (this seems to imply that "torpedoes" fire is akin to air battles)) doesn't automatically implies that the casualties are being removed from the game before the battle starts (for example, in the v3 rules set, naval bombardment happens even before any AA fire (here I'm talking about the correct rules, not the program behaviour), yet casualties from naval bombardment are not removed once the naval bombardment step is over).
Since, as now, "targeted" (AA) fire doesn't admit fire back from casualties making normal fire, here the matter is simply to document in notes that casualties from "torpedoes" fire are removed from the battle immediately (or not added to the battle at all, if it is preferred to keep the "firing before a battle" concept).
Regarding the eligible targets of cannonades, according to the descriptions in notes, "artillery" cannonades should target any combat unit but "cavalry" and "elite_cavalry". According to the descriptions in notes, "fieldwork" cannonades should target any combat unit.
However, the game behaviour is that "engineers" are eligible targets for all cannonades.
Therefore, there is the problem that "artillery", "entrenchments" and "fortifications" can all target also "engineers", with cannonades, while they should be unable to (or, rather, to use the notes' perspective, "engineers" should be unable to be targeted by cannonades).
To aggrieve this issue (and this is a fault with the program rather than with the map, even though the map could have had customized tooltips, especially on the account of its complexity), the program fails to show any information on the targets of the "cannonades" targeted fire, via the automatically generated tooltips (you can get by clicking on "Help/Unit Help"), as you cannot see which ones are the eligible units (for example, the "fortifications" has only "Targeted Defense for Combat: 2/12 fortifications_cannonade with 12 Attacks for Unlimited Rounds", and I believe there is no way to know what the eligible targets are, by reading the tooltips only).
More generally, I think it is also unexpected that engineers can be used as pure fodder in attack (I'm not saying it is wrong).
These are the targets for the targeted shots of any unit having such ability:
artillery:
<option name="targetsAA" value="militia:infantry:elite_infantry:artillery:engineers"/>torpedo:
<option name="targetsAA" value="gunboat:ironclad:frigate:battleship:transport"/>entrenchments:
<option name="targetsAA" value="militia:infantry:elite_infantry:cavalry:elite_cavalry:artillery:engineers"/>fortifications:
<option name="targetsAA" value="militia:infantry:elite_infantry:cavalry:elite_cavalry:artillery:engineers"/>
Nowhere in notes it is even tentatively communicated that "cannonades" casualties or targets (not sure how it exactly works) are selected randomly amongst all eligible targets (additionally to the fact that every target can be targeted by no more than one cannonades from the same unit type at the same time).
For example, for "entrenchments", this is the relevant description:
Defender's fieldworks fire long-distance bombardments, rolling at 1/12 (for entrenchments) or 2/12 (for fortifications) against each eligible enemy attacker.
And this is the relevant property:
cannonade rolls against up to 12 attackers @1
What I understand out of this, when an "entrenchments" does its cannonades and more than 12 targets are eligible, is that someone or something first determines what are the 12 units that are being targeted, then one dice for each of them is rolled, to determine whether or not the unit is removed from the game. The same for "fortifications" and "artillery" cannonades. However, I believe nowhere it is explained how the 12 targets are selected.
The current behaviour appears to be that such casualties selection is purely random (amongst all the eligible targets) (but I cannot be sure this is indeed how the system works).
If the behaviour is intended, whatever it is, it should be documented in notes (especially since in the moment something is automated, a normal user cannot know if it is purely random or it follows some pattern).
For reference, these are the relevant "AA" related properties in the game file:
<property name="Roll AA Individually" value="true" editable="false"> <boolean/> </property> <property name="Choose AA Casualties" value="false" editable="false"> <boolean/> </property>
Nowhere in notes it is even tentatively communicated that "torpedoes" casualties or targets (not sure how it exactly works) are selected randomly amongst all eligible targets (additionally to the fact that every target can be targeted by no more than one torpedo at the same time).
Specifically, this is the relevant description:
Each torpedo rolls at 3 at one ship. To target more ships you need more torpedoes.
And this is the relevant unit information:
roll at 3 for 1 ship before combat
What I understand out of this and assuming that every target can be targeted by no more than one torpedo at the same time, when a number of "torpedoes" roll and more than that number of targets are eligible, is that someone or something first determines what are the units, in a number equal to the number of torpedoes, that are being targeted, then one dice for each of them is rolled, to determine whether or not the unit is removed from the game. However, I believe nowhere it is explained how the targets, in a number equal to the number of torpedoes, are selected.
The current behaviour appears to be that such casualties selection is purely random (amongst all the eligible targets) (but I cannot be sure this is indeed how the system works).
If the behaviour is intended, whatever it is, it should be documented in notes (especially since in the moment something is automated, a normal user cannot know if it is purely random or it follows some pattern).
For reference, these are the relevant "AA" related properties in the game file:
<property name="Roll AA Individually" value="true" editable="false"> <boolean/> </property> <property name="Choose AA Casualties" value="false" editable="false"> <boolean/> </property>
The "breastwork", "entrenchments" and "fortifications" have, respectively, the following descriptions in the legend on the map: "-1 att. x2", "-1 att. x4" and "-2 att. x6".
However, both the behaviour of the engine and the descriptions in the notes have them acting both in offence and defence.
Therefore, if the notes and the behaviour are correct, the legend on the map should say "att./def.", instead of only "att.", in all mentioned cases.
I realize that the legend on the map is incomplete in several other cases (for example, the legend on the map doesn't tell that the supports from "breastwork", "entrenchments" and "fortifications" apply to enemy units (whether or not this might be an issue depends on whether or not the legend on the map is supposed to give full information)), and this is probably intended, as I suppose the notes are supposed to be the only place where to give full information. However, I would call this a case of wrong (not merely incomplete) information, as saying only "att." for something that applies both to "attack" and "defence" is more like wrongly specifying that the ability in question is "attack only" (or at least it is liable to be read this way), rather than leaving unspecified whether it applies to defence too or not.
On a related note, I cannot imagine why "entrenchments" and "fortifications" are able negatively to support enemy units while attacking or defending all the same, while they are able to make "cannonades" against these same units, plus "engineers", only while defending. I would rather expect both the support and the "cannonades" abilities applying either both in attack and defence or in defence only. I think this also makes the game harder to learn, as you have to remember what, amongst the abilities of "breastwork", "entrenchments" and "fortifications", is working in attack too, as opposed to just knowing whether or not they generally apply in attack too.
Both the legend on the map and the notes miss to clarify the actual targets of the negative generic supports from "breastwork", "entrenchments" and "fortifications".
The behaviour is that the supportable units are "elite_infantry", "elite_cavalry", "cavalry", "artillery", "infantry" and "militia".
While I think it is reasonable that, by "enemy units", it is meant any unit that may be in combat on the opposite side of this unit and having a positive attack or defence value, which would be all units of the "combat unit" class (that indeed are "militia", "infantry", "elite infantry", "cavalry", "elite cavalry" and "artillery"), I believe it is opportune to clarify the targets even in case they simply are all possible and useful ones (the possible but not useful one would be the "engineers" unit (which is not a target)). This can be handily done by saying, for example, "to 6 enemy combat units" (or whatever the name the class), instead of "to 6 enemy units".
The "fortifications" is documented on the map as "-2 att. x6" and in notes as "-2 att/def to up to 6 enemy units". So, if reading "-2 att. x6" as "-2 att./def. x6", the fortifications unit should give -2 support to 6 units of the opposite side, apparently.
However, a "fortifications" actually only gives -1 support to each of them.
Assuming the descriptions are correct, the "fortifications" behaviour should be changed as to give -2 bonus (that is a malus of 2).
It is not stated anywhere in the legend on the map nor in notes whether the "breastwork", "entrenchments" and "fortifications" generic maluses to other units cumulate or not with each other. The notes just say something like "-1 att/def to up to 2 enemy units" and the support is not specifically identified with a name. Therefore, one may wonder whether the support is specific to the unit type only, rather than to the class, or any other archetype, or it is general. In the first case, such "fieldwork", "entrenchments" and "fortifications" supports would be different supports, thus cumulative (meaning that the same unit should be able to receive support from each of them, for up to a -4 total bonus (as per the TripleA behaviour, the full malus would be given (thus wasted) even if it would give negative strength to the unit, but actually only bringing the unit strength down to 0, wasting the exceeding support modifier)), while, in the second case, the same unit could be supported only by one unit amongst every "fieldwork", "entrenchments" or "fortifications" unit that may support it (in this case, it would be necessary knowing how priorities are defined, if the unit must receive only one of multiple supports).
Behaviourally, the supports are not cumulative, since they share the same type, in the game's file's coding.
If the behaviour is intended (as it most likely is), the notes should be clear about it (making clear that the same unit can never be concurrently supported by more than 1 of any unit of the "fieldwork" class).
These are the supports in question (from the game file):
<attachment name="supportAttachmentBreastworkInfantry" attachTo="breastwork" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="2"/> <option name="bonusType" value="fieldwork"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentEntrenchmentsInfantry" attachTo="entrenchments" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="4"/> <option name="bonusType" value="fieldwork"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentEntrenchmentsInfantry" attachTo="fortifications" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="6"/> <option name="bonusType" value="fieldwork"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment>However, since, as said, the "fortifications" are supposed to give a -2 malus to each of the units they support, once that is fixed, the actual supports would be these ones (I've also reworked the names for no necessary reason):
<attachment name="supportAttachmentFieldwork" attachTo="breastwork" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="2"/> <option name="bonusType" value="fieldwork"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentFieldwork" attachTo="entrenchments" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="4"/> <option name="bonusType" value="fieldwork"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentFieldwork" attachTo="fortifications" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-2"/> <option name="number" value="6"/> <option name="bonusType" value="fieldwork"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment>If the actual supports are changed to work as per the intended rules (as described), and assuming each of the supported units is meant to be supported by no more than one of these, it would be necessary to document, and possibly define, supporting priorities.
Assuming it is wanted strongest supports being applied first, the matter would be to assure that the strongest support is applied first, also documenting such behaviour (since this is not documented too).
For example, if there are 8 infantry units attacking, as the only attacking units, and in the territory there is 1 "entrenchments" and 1 "fortifications", it must be made sure that the maluses from fortifications are applied first, so that 6 of the units get -2 and 2 of the units get -1, wasting a total of 2 support power from the entrenchments, instead of wasting a total of 4 support power from the fortifications (if the entrenchments support would be applied first, 4 units would get -2 and 4 units would get -1, while 2 bonuses of -2 would remain unassigned, thus wasting 4 support power from the fortifications), or whatever other combination.
However, the problem with this is that there is no way by which to prioritize supports, as far as I know (I actually don't know if the program somehow infers what the most effective supports are and, then, prioritizes them), nor any way clearly to determine what supports get precedence when there are more supports than receivers. On this matter, whatever the current behaviour is, I believe it is not documented anywhere (at least not anywhere accessible to non-developers). So, I believe here it would be pre-emptively needed a developer to document the behaviour, if not making a way (adding a new feature) actually to specify such preference.
Is what I just said correct ( @redrum, @LaFayette, @RoiEx or any developer)? For example, in case of having a series of supports like the three "supportAttachmentFieldwork" above, if, with these supports, it happens that there are more total number of supports to be given than the number of supportable units, how does the engine determines which ones of the different (but same type) supports are used? As the owner of the supporting units, if no malus would exceed the strength of the target unit, what you likely want to do is using the one attached to "fortifications" first (because it is the strongest one). Is the program somehow inferring this or is there a way to assure such optimal behaviour (I actually made a feature request for ordering supports, but that feature request refers to define priorities amongst the supported units, not amongst the supporting ones, thus it would be of no use here)?
If one cannot rely on the engine (can we?) to use the most effective supports first, or alternatively to it, a possible workaround, to assure such behaviour, would be recoding supports as per the following code (assumingly, as I've not tested it):
<attachment name="supportAttachmentFieldwork1" attachTo="breastwork" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="2"/> <option name="bonusType" value="fieldwork1"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentFieldwork1" attachTo="entrenchments" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="4"/> <option name="bonusType" value="fieldwork1"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentFieldwork1" attachTo="fortifications" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="6"/> <option name="bonusType" value="fieldwork1"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentFieldwork2" attachTo="fortifications" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="elite_infantry:elite_cavalry:cavalry:artillery:infantry:militia"/> <option name="faction" value="enemy"/> <option name="side" value="offence:defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="6"/> <option name="bonusType" value="fieldwork2"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment>Per the support attachments above, the -2 from fortifications would be split into two different supports, one ("fieldwork2") and the other one ("fieldwork1") respectively cumulative and non-cumulative with the other "fieldwork1" supports. This practically assures that the intended -2 support (actually split into two reciprocally cumulative supports of -1 each) will be applied before any -1 ones. A downside of this is that, obviously, the automatic tooltips about such supports will be likely very unclear to most users (even if technically correct and theoretically understandable).
There are special maluses for cavalry or cavalry-like units only, defensively given by each of the three "fieldwork" units, that are maybe and partially documented only as "enemy cavalry attack as infantry (dismount)", in the legend on the map and in each of the fields for the "entrenchments" and "fortifications" units in the "other properties" column of the "unit information" table in notes.
Both on the map and in notes no further information is given, on the matter, as far as I can tell.
The foremost problem of such lack of complete information (if not complete lack of information), I think, is the fact that it is not even clear what "enemy cavalry attack as infantry (dismount)" actually means, to start with.
The first understanding issue of this rule is that, from a game notes perspective, there are no "cavalry" nor "infantry" classes, thus the rule could be literally only read as referring to the units specifically called, respectively, as "infantry" and "cavalry" (therefore being irrelevant for the unit called as "elite_cavalry"). However, also on the account that, if the reference would be to the units' types, the rule would be completely pointless, as "infantry" and "cavalry" have both the same attack value, it is fairly obvious to assume that "enemy cavalry attack as infantry" means the following two things:
- "enemy cavalry attacks as infantry".
- "enemy elite_cavalry attacks as elite_infantry".
In this case, my understanding of all of this, as documented in the legend on the map, would be that the attack strength of "cavalry" and "elite_cavalry" are, respectively, equal to "infantry" and "elite_infantry", when attacking a defensive force comprising at least one "entrenchments" or at least one "fortifications", or both.
In turn, this interpretation would automatically exclude point 1, because, as anticipated, "infantry" and "cavalry" have the same attack strength (equal to 2 in both cases), thus saying that "enemy cavalry attacks as infantry" would be irrelevant, if referring to the attack strengths of the units called "cavalry" and "infantry" (nothing changes). Therefore the rule would actually equal saying only "enemy elite_cavalry attacks as elite_infantry" or, more precisely, "-1 attack malus to all "elite_cavalry" if the defending units comprise one or more units each of which is an "entrenchments" or a "fortifications"".
An alternative interpretation of the "enemy cavalry attack as infantry (dismount)" rule (that has been put forward by @wirkey) may be that it would be a reference (or rather a hint) to the fact that the "cannonades" ability of the "entrenchments" and "fortifications" are (behaviourally and according to the notes) able to target also "cavalry" and "elite_cavalry", differently from the "artillery" cannonades, which cannot. This interpretation would at least explain why such reference is absent for "breastwork" (since this unit is able to make no "cannonades") and would have the merit of at least vaguely attempting to address the issue of completely lacking anything in the legend on the map that differentiates the "cannonades" ability of "artillery" and "entrenchments" in any way (while, behaviourally and according to the notes, the artillery cannonades cannot target "cavalry" and "elite_cavalry", while the entrenchments and fortifications cannonades can). However, especially since the numeral "3", that calls the "enemy cavalry attack as infantry (dismount)" note, is immediately after the "-1 att. x4," and "-2 att. x6," descriptions, I think this note is really related to the negative supports abilities, as an integration of them (and additional support on top of the ones described), not to any cannonades rules (it is still confusing to me, as I would rather expect that being something related to those supports, rather than an other support). Besides, something described merely as "cannonades at 1" and "cannonades at 2", without any additional clarification, quite clearly implies that you have to go reading the notes for an explanation of what cannonades are, to start with (still, I believe it is a missing item that the legend appears to imply that the cannonades of "artillery" and "entrenchments" are just exactly the same in all matters (but I tend to see it more as a missing item for the "artillery", that should specify its "cannonades" cannot hit "cavalry" nor "elite_cavalry")). Finally, if "enemy cavalry attack as infantry (dismount)" would mean that the cavalry (whatever this means) can be hit by "cannonades", then this would imply that also the "artillery" cannonades should be able to hit "cavalry" when defending a zone occupied also by one "entrenchments" or one "fortifications, or both. For all these reasons, as said, I tend to dismiss the hypothesis that "enemy cavalry attack as infantry (dismount)" may mean anything like that "enemy cavalry becomes a cannonades target of something". Moreover, it would either make no sense or be wrong (arguably) for the notes to have this meaning for "enemy cavalry attack as infantry (dismount)", since, in there, the targets of each "cannonades" able unit are already detailed.
However, if this understanding of mine of the "enemy cavalry attack as infantry (dismount)" rule is even correct (meaning that this rule exactly equals saying "-1 attack malus to all "elite_cavalry" if the defending units comprise one or more units each of which is an "entrenchments" or a "fortifications""), the rule is inconsistent with the game behaviour on three items.
One inconsistency is that "breastwork" doesn't have such a reference in the legend on the map nor in notes (thus shouldn't have such supporting ability at all), while, behaviourally, it gives -1 attack to all enemy cavalry (not to elite_cavalry).
An other inconsistency is that "entrenchments" gives the malus to enemy "cavalry", instead of giving it to enemy "elite_cavalry".
The other inconsistency is that "fortifications" gives the malus to enemy "cavalry" and "elite_cavalry", instead of giving it only to "elite_cavalry".
The inconsistencies detailed for "entrenchments" and "fortifications" also generate another inconsistency, since there is nothing at all that even hints to the fact that the "anti cavalry" supports from the "fieldwork" units might have different possible targets per type of unit (depending on the interpretation of the rules, I believe one would either assume that they all apply to "cavalry" and "elite_cavalry" all the same (this being the behaviour for "fortifications") or they all apply to "cavalry" only (this being the behaviour for "entrenchments") or they all apply to "elite_cavalry" only (this last one being my interpretation (which is the behaviour of nothing))).
For information, these are the supports in question (from the game file):
<attachment name="supportAttachmentBreastworkCavalry" attachTo="breastwork" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="cavalry"/> <option name="faction" value="enemy"/> <option name="side" value="defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="999"/> <option name="bonusType" value="anti-cav"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentEntrenchmentsCavalry" attachTo="entrenchments" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="cavalry"/> <option name="faction" value="enemy"/> <option name="side" value="defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="999"/> <option name="bonusType" value="anti-cav"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment> <attachment name="supportAttachmentEntrenchmentsCavalry" attachTo="fortifications" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="cavalry:elite_cavalry"/> <option name="faction" value="enemy"/> <option name="side" value="defence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <option name="number" value="999"/> <option name="bonusType" value="anti-cav"/> <option name="impArtTech" value="false"/> <option name="players" value="Union:Confederate"/> </attachment>An inconsequential naming inconsistency is that the support attached to "fortifications" is named "supportAttachmentEntrenchmentsCavalry". On this regard, I'm not sure whether every support attachment is supposed to have an unique name or same names for different support attachments attached to different units are fine (for example, can the three supports above have the same name, or should they have different names?) ( @redrum, @LaFayette, @RoiEx or any developer).
Generally speaking, I believe that, in every game, the user should be able to know exactly and unmistakably how everything is going to work before ever playing the game. Since TripleA doesn't actually have an automated way to gather the settings and furnishing the user full information about the behaviour that are to be encountered upon playing the game (this is only partially done through the automated unit tooltips), in order to assure this, the game should tell the user what is going actually to happen, without him requiring actually to play-test the map, in order tentatively to acquire any such information. This can, of course, be done by furnishing a full rulebook, explaining everything in the smallest details, in notes. For the experienced TripleA player, this can be reduced to explaining "only" every single thing that does not always work only one way in TripleA, albeit this approach has the problem that exceptions may be added in the future (so something that now always works the same way in TripleA, like, say, the fact that attackers roll their dice before the defenders, may be not still true if, in the future, you would have the ability to make the defenders go first). Alternatively (and this is how it is usually done in TripleA if at all) you can reference the main basic rules set the game is following, then proceed to detail every exception to it.
The official list of rules set for TripleA is here:
https://github.com/triplea-game/triplea/wiki/Game-Rule-SetsFor example, when I start the game I may wonder whether or not I can blitz through territories with capturable units. If I'm a very knowledgeable TripleA player, I should know that this is possible under the v1 rules set but it is not possible under any rules set from v2 to v6. Currently, I believe there is no way for the player to know what the behaviour is going to be, besides playing the game. Such a knowledge can be assured, instead, as I said, by:
1- Writing in notes the entire rulebook, fully explaining how the game works (thus also containing the information that I can always blitz through territories that are either empty of enemy units or occupied by one or more enemy units each of which are capturable (comprising units that are not normally capturable, but are so because of being owned by a "friendly neutral")).
2- Writing in notes that v1 rules apply to this game (since, under these rules, you can blitz through capturable units, you don't need to specify this is possible, but you will need to specify any deviation from v1 rules).
3- Writing in notes that v2 basic (or v2 LHTR, or v3, or v4, or v5) rules apply to this game, but then also adding that, contrary to these rules, you can blitz through capturable units (you will also need to specify every other deviation from the rules).To make a few more examples of what I mean here, other things a user may wonder is whether or not he is allowed intentionally to over-purchase. If over-purchasing, then, the next question would be what will happen to units that are purchased but not placed (will they be lost, will they be kept in the inventory, will they be refunded?). And so on. There is really a considerable amount of possible behaviours for various items that the user should be aware of, without having to learn them "the hard way". The notes have the duty of doing this, currently, since the TripleA program is incapable of fully communicating what's defined inside the game (XML) file.
On top of this, there are several items that TripleA doesn't fully enforce (for example, TripleA doesn't oblige you to place the maximum number of units you can possibly place (for example, TripleA allows you to decide not to place something you can place in addition to anything else, but this is an illegal move), which might be particularly relevant for an upkeep based game). For any such item, only a rulebook or a clear reference to a rules set (used as the basis) is the way to know not only what to do but also what not to do.
To be clear, everything at this topic is supposed to be mainly actual problem reports (waiting for someone to fix them on the map, on the engine or both (nothing at all of what reported at this topic has been fixed, so far, as far as I know)). I simply moved this topic out of the "Bug Reports" section after the section has been "archived".
As far as I know, nothing of what has been reported or discussed in this topic, excluding anything off the topic itself, has been ever ported into the map in any way. So everything on topic posted in this topic should be still fully relevant and "open", nothing of it having ever been fixed in any way, as far as I know.
open AAA/Paratrooper issue in v3 #5834
