Stack Unit Support
-
@redrum In that case, I'd go for a stack number (I guess 0 may mean infinite).
-
@redrum
Instead of adding a new 'canStack' property, why not just add the 'count' value to the 'bonusType' property. So for @Frostion's Siege-Tower:<option name="bonusType" value="Cover" count="3"/>would allow 3 Siege-Towers to stack the support together.
The absent of count would equal 1. So if @Frostion had a Battering-Ram and its supportAttachment:
<option name="bonusType" value="Cover"/>Then the Battering-Ram could not stack support with itself, but it would still stack with the Siege-Tower so that:
2 Siege-Towers would equal -2 support for enemy fortifications
1 Siege-Tower and 1 Battering-Ram would equal -2 support for enemy fortifications
2 Battering-Rams would equal just a -1 support for enemy fortifications.
1 Siege-Tower (count="3") with two Battering-Rams would still gain the -3 support.Just some thoughts.
Cheers...
-
@wc_sumpton I like that idea.
@Frostion @wc_sumpton @Cernel I think my only question here is would a map maker ever want to set a different bonusType count for different units with the same bonusType string? So for example if I had 2 different unit types that provide "cover" support would I ever want them to have different counts (or should they always set the same count) and if I'm not sure exactly how that would work?
So is something like this useful or should the counts always be the same for a given bonusType?
<attachment name="supportAttachmentSiege-Tower" attachTo="Siege-Tower" javaClass="UnitSupportAttachment" type="unitType"> <option name="bonusType" value="Cover" count="2"/> </attachment> <attachment name="supportAttachmentSomeOtherSiege" attachTo="SomeOtherSiege" javaClass="UnitSupportAttachment" type="unitType"> <option name="bonusType" value="Cover" count="1"/> </attachment> -
So I don't see any reason to support different counts for the same bonusType. Here are some initial examples of this feature.
Infantry receives support from up to 2 artillery
<attachment name="supportAttachmentArtillerygerman" attachTo="germanArtillery" javaClass="UnitSupportAttachment" type="unitType"> <option name="unitType" value="germanInfantry:germanMarine:germanCombatEngineer:germanAlpineInfantry:germanParatrooper"/> <option name="faction" value="allied"/> <option name="side" value="offence"/> <option name="dice" value="strength"/> <option name="bonus" value="1"/> <option name="number" value="1"/> <option name="bonusType" value="ArtilleryBonus" count="2"/> <option name="impArtTech" value="false"/> <option name="players" value="Germany"/> </attachment>Infantry receives support from up to 3 static defenses (entrenchment, fortification)
<attachment name="supportAttachmentEntrenchmentgerman" attachTo="germanEntrenchment" javaClass="UnitSupportAttachment" type="unitType"> <option name="unitType" value="germanInfantry:germanMarine:germanCombatEngineer:germanAlpineInfantry:germanParatrooper:italianInfantry:italianMarine:italianCombatEngineer:italianAlpineInfantry:italianParatrooper:japaneseInfantry:japaneseMarine:japaneseCombatEngineer:japaneseAlpineInfantry:japaneseParatrooper"/> <option name="faction" value="allied"/> <option name="side" value="defence"/> <option name="dice" value="strength"/> <option name="bonus" value="1"/> <option name="number" value="2"/> <option name="bonusType" value="FortBonus" count="3"/> <option name="impArtTech" value="false"/> <option name="players" value="Germany"/> </attachment> <attachment name="supportAttachmentFortificationgerman" attachTo="germanFortification" javaClass="UnitSupportAttachment" type="unitType"> <option name="unitType" value="germanInfantry:germanMarine:germanCombatEngineer:germanAlpineInfantry:germanParatrooper:italianInfantry:italianMarine:italianCombatEngineer:italianAlpineInfantry:italianParatrooper:japaneseInfantry:japaneseMarine:japaneseCombatEngineer:japaneseAlpineInfantry:japaneseParatrooper"/> <option name="faction" value="allied"/> <option name="side" value="defence"/> <option name="dice" value="strength"/> <option name="bonus" value="2"/> <option name="number" value="3"/> <option name="bonusType" value="FortBonus" count="3"/> <option name="impArtTech" value="false"/> <option name="players" value="Germany"/> </attachment> -
@redrum I don't think I've a particular interest in any matters at this thread, so whatever @Frostion so @wc_sumpton prefer don't mind me, but I think the main argument for supporting different support counts is that, for the way it is coded, you have to support them, unless you address the situation some other ways, like making the game crash if the mapmaker set a same "bonusType" having different counts. So, I would definitely support them, even only for this.
-
@Cernel Well they will work but the engine will just select the first one it finds as it will assume they are all the same for a given bonusType. I don't think it makes sense to have different counts for the same bonusType as really at that point you should probably be using different bonusTypes.
-
@redrum said in Is it possible to make this unit's negative AA support stack?:
@Cernel Well they will work but the engine will just select the first one it finds as it will assume they are all the same for a given bonusType. I don't think it makes sense to have different counts for the same bonusType as really at that point you should probably be using different bonusTypes.
Meh. I think this is really unpolished. I'd rather crash, really, or at least giving an exception, telling that something is wrong.
-
The other question is how the multiple support should work? Should we first down a same unit as much as we can, or should be first down as many units as we can, then go back downing again what we already downed.
For example, if I have 2 artilleries that each can support 1 enemy infantry at -1, but stack up to 2 supports per infantry, if I'm attacking 2 infantries should they be both downed by 1, or only 1 downed by 2, and the other one unaffected?
-
-
@Cernel It will try to stack as many support as allowed to each unit 1 by 1. So if you had an artillery that has count=2 and you have 2 inf and 2 art then both art would support the same inf. I think you can debate this either way but its much easier to code using as much support as possible to each unit 1 by 1.
-
@redrum said in Is it possible to make this unit's negative AA support stack?:
@Cernel It will try to stack as many support as allowed to each unit 1 by 1. So if you had an artillery that has count=2 and you have 2 inf and 2 art then both art would support the same inf. I think you can debate this either way but its much easier to code using as much support as possible to each unit 1 by 1.
Ok, I don't have a definite opinion on this, at the moment, but that would be important to document in pos2, and it is good to know, for further reasoning on cases of same type and different counts.
I'm curious about @Frostion too, and, again, whatever @Frostion or @wc_sumpton are thinking go with it, I don't mind, but, if I must try to see a way to justify different support counts, I can see the case of "light_artillery" and "heavy_artillery".
Both artilleries have a support reducing the defensive strength of enemy infantries, but the light artillery is more superficial, so it can reduce it only up to 1, while the heavy artillery can bring it down by up to 2. Beside this only, both artilleries have exactly the same kind of support, for 1 enemy infantry at -1 (so, the heavy artillery doesn't have a heavier support, just one that, let's say, "goes deeper").
So, against, say, two infantries, you could have the dynamic that you could send, for example:
- 2 light artilleries, to down both infantries by 1.
- 2 heavy artilleries, to down only 1 infantry by 2 (if we go this way).
- 3 heavy artilleries, to down 1 infantry by 2 and 1 infantry by 1.
- 4 heavy artilleries (or more), to down both infantries by 2.
- 2 light artilleries and 2 heavy artilleries, to down both infantries by 2.
Here, then, the dynamic would likely be that, for some reasons, it would be more efficient having 2 light artilleries and 2 heavy artilleries, instead of 4 heavy artilleries. This may represent the heavy artillery focusing on doing what the light artillery cannot achieve, while the heavy artillery being overkill (thus inefficient) for what can be covered by the light artillery. A similar example could be done if you would have howitzers and cannons, where the howitzers would be as good as cannons, but having shorter range and being cheaper (so, it would be more efficient to use howitzers at the distances they can cover, and cannons only for covering beyond that, but you could use only cannons, instead).
To consistently support this, it should be assured that, for the same type of supports, either the ones with the lowest count are applied first, or somehow the program backtracking the matter, so to apply support in the most efficient way (meaning that, for example, in the case we have 3 heavy artilleries and 1 light artillery downing 2 infantries, if we first apply the 3 heavy artilleries supports, to down 1 infantry by 2 and 1 infantry by 1, then we can still down the last infantry by an additional 1, with the light artillery, like we could have done if we applied the light artillery support first).
Again, I'm just considering the matter now that it is coming out. I've no plans to use any of this, at the moment, but you never know.
-
@Cernel Yeah, its an interesting example though fairly complex. I think I'm not going to go that far with this initial feature since as you point out it adds some complexity to the ordering that you would need to ensure applying supports of a bonusType that had different counts (in your example applying all light artillery before heavy artillery). I'd rather keep it simpler and address the original request around just allowing some mechanism for stacking and for now it will work at the bonusType level in terms of the count.
-
@redrum In that case, I think it would be cleaner doing it with a property calling a specify "bonusType", assigning a count to it.
-
@Cernel The issue with a property is you'd have to specify both which bonusType and the count. I also don't really want to add a global property for something that fits better with supportAttachment. While the duplication of the count across supportAttachments with the same bonusType isn't great, most maps don't tend to have very many units with the same bonusType.
-
@wc_sumpton @redrum @Cernel
My only thought was/is that it would be cool if a single unit type could be set to be able to stack its support with other units of same type.Like two or more “siege-Tower”s could stack/combine their support/efficiency.
I like the idea of a count, so that there can be a max on the stacked-support.I am sure you guys can sort out all the details of this matter

-
@Frostion I had a feeling you would say that

Here is the PR: https://github.com/triplea-game/triplea/pull/5309
To go back to your original question, here is what you'll be able to do now to allow 2 Siege Tower to stack their negative support against a fort:
<attachment name="unitAttachment" attachTo="Fort" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="isFactory" value="true"/> <option name="isInfrastructure" value="true"/> <option name="canProduceXUnits" value="2"/> <option name="attackAA" value="2"/> <option name="attackAAmaxDieSides" value="10"/> <option name="maxAAattacks" value="10"/> <option name="maxRoundsAA" value="-1"/> <option name="isAAforCombatOnly" value="true"/> <option name="typeAA" value="Wall Archers"/> <option name="mayOverStackAA" value="true"/> <option name="damageableAA" value="true"/> <option name="targetsAA" value="$AllLandUnits$"/> </attachment> <attachment name="supportAttachmentSiege-Tower" attachTo="Siege-Tower" javaClass="games.strategy.triplea.attachments.UnitSupportAttachment" type="unitType"> <option name="unitType" value="$AllFortifications$"/> <option name="faction" value="enemy"/> <option name="side" value="offence"/> <option name="dice" value="AAstrength"/> <option name="bonus" value="-1"/> <option name="number" value="1"/> <option name="bonusType" value="Cover" count="2"/> <option name="players" value="$AllPlayers$"/> </attachment> -
@redrum Not sure you got what I meant. The property would be akin to:
<property name="Axis Economic Victory" value="120" editable="false"> <number min="0" max="1000"/> </property>That one calls an alliance called exactly as "Axis". In my example, you would call a bonus type called exactly as the first or last word in the property (I would do the last).
I don't really care much; I just feel it is very incoherent to have something that it is supposed to be set the same for all cases but a coding that allows setting it specifically for each case. So, I definitely suggest either making this with a property or supporting different counts for each case.
-
@redrum said in Stack Unit Support:
I think I'm not going to go that far with this initial feature since as you point out it adds some complexity to the ordering that you would need to ensure applying supports of a bonusType that had different counts (in your example applying all light artillery before heavy artillery).
Ordering is already relevant, but not documented, actually: on the matter of in what orders multiple supports with the same type are applied, can that be defined or, if already defined, can that be fully documented in pos2?
An example would be having an "artillery" and a "horse_artillery" unit, that have exactly the same support specifics, except that "artillery" can support only "infantry", while "horse_artillery" can support "infantry" and "cavalry". In this example, if we apply first the support from "horse_artillery", and that support effects 1 infantry unit, then, if there are no more infantry units, the support from "artillery" would be wasted. I actually tested something like this case, and I've always seen it working the best every time, maximizing support assignement, but the problem is that this is something that I assume it may work this way for having tested it a few times, but it would be good having it clarified in pos2, as currently I don't even know if I'm even supposed to have something like this.
If a developer can clarify this matter here, I suppose I can push the update to pos2 myself. Thanks.
Practically what I'm asking is documenting in pos2 in what order supports are applied (relevant only in case they are of the same type).
-
@Cernel "Working the best every time" is not possible. Even with relatively simple support attachments there can be battles where there is no optimal solution to apply support, in the sense that for every possible way of applying support at least one of the players would want to change how his own units give support. So the best we can possibly do is to come up with some clear rule and stick to that, even in cases when a player would want to do it differently.
Example: Player A has two 3/3 units and a 0/0 unit, Player B has two 6/6 units. One of Player B's units gives -3 power to any one of Player A's 3/3 units, while Player A's 0/0 unit gives +3 power to any one of his own 3/3 units. If both the -3 and the +3 are applied to the same unit, Player A has a 25% chance of winning, whereas if they are applied to different units, the chance is 0%.
-
@alkexr said in Stack Unit Support:
@Cernel "Working the best every time" is not possible.
By "working best every time" I was referring to the case I mentioned and it actually meant supporting the greatest possible amount of units. In the case I mentioned (horse_artillery being exactly the same as artillery, except also able to support cavalry), this would be practically assured by applying the bonus from artillery first. So, in this case, I would be interested in documenting how a mapmaker can define the order in which supports are applied.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login