Stack Unit Support

[Cernel]

@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.

[redrum]

@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.

[Cernel]

@redrum In that case, I think it would be cleaner doing it with a property calling a specify "bonusType", assigning a count to it.

[redrum]

@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.

[Frostion]

@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

[redrum]

@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>

[Cernel]

@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.

[Cernel]

@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).

[alkexr]

@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%.

[Cernel]

@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.

[Cernel]

@Frostion I understand that, if, in the case of your game, you never have more than one fort in the same territory, the system should work fine, as you would make a support attachment for each level of fortification, but this would be still something that works only under that limitation. Instead, I don't think that this system really broadly covers cases like yours, if you would not have that major limit of only 1 fortification of any kind per territory: when having a fortification level 1, then a fortification level 2; the first one being able to be supported once, and the second one twice, with a single support attachment like the current proposal, either they can be both supported once or twice, only (likely starting from the weakest one, as this is how it usually works), so you cannot generally have the dynamic of a siege engine that supports once the first level of fortification and supports twice the second level, etc. (unless, as said, those levels are never present together).

I would actually put the count on the target, not on the giver. Meaning that a same supportattachment could be assigned a different number of times for each target (in this case, you would also need only 1 supportattachment in total, that can be given only once to the units being the first level of fortification, up to twice to the units being the second level, etc.).

I also personally believe that the limit of 1 fort per territory doesn't really make sense, realistically, in a strategic game, as you could have territories with more castles or whatever, stacked in them, rather than just either 0 or 1, but this is just my personal view. This is how it works for static combat units in almost all TripleA games (it's rare to have a stack limit of 1 bunker or whatever).

[Captain Crunch]

@Cernel hey Cernel you are my fav nerd

I just wondered what maps you made???

And I really like your knowledge of history and I wonder if you are older than me Im late 40's

[Cernel]

@Captain-Crunch I've not much on the repository (well, I made Conquest of the World, but that was wanted by @LaFayette and I thought it was a very good idea adding Risk as a matter of getting new players in the community), and currently just a bunch of variants/mods. The one I like the most is "270BC 40%" (I intend to rename it "270BC Cernel Lite"). The main one I hope to eventually complete is a medieval 5 sides game set in 1181. I'll of course open a thread if I get it done.

[Captain Crunch]

@Cernel oh well im just picturing you as older than me is why I asked

[redrum]

This is now merged and can be tested in the pre-release. POS2 XML update here: https://github.com/triplea-maps/the_pact_of_steel/pull/35/files

[Cernel]

@redrum said in Stack Unit Support:

This is now merged and can be tested in the pre-release. POS2 XML update here: https://github.com/triplea-maps/the_pact_of_steel/pull/35/files

To be clearer to everyone, I would reword this:

Any support of the same bonusType MUST have the same count.

to this:

In case you have multiple support attachments with the same "bonusType", you should assign all of them the same count, as well (different counts for different attachments for the same type of support are not supported).

About this line:

Please us the string "ArtyOld" if do not want your bonus to stack with normal artillery (ie: do not want the bonus to stack with any unit with the normal artillery attachment: <option name="artillery" value="true"/>)

Are you sure about this wording? I mean keeping it? Are you calling "normal" something that is deprecated, isn't it? I would rather reword this as telling or implying that this is what it is going to happen, but not actively suggesting makers to mix up the two ways of defining support in the same game. Like, I would say something purely technical like this:

The artillery option (for units attachments) <option name="artillery" value="true"/> generates a support attachment (attached to that unit) that has "bonusType" value equal to "ArtyOld" (with default count of "1").

[Frostion]

@redrum
I have tested it out. At first glance it seems to work fine. In my World of War Heroes map I now have:

5 levels of fortification (From "Watch-Tower" to "Capital-City") and they have 1-5 "Wall Archers" shooting at attackers, and hitting 8/10 of the time.

1 "Battering-Ram" that lowers all "Wall-Archers'" hit chance, on any type of fortification, by 50%, from 8/10 to 4/10. Symbolizing that the enemy runs through under the battering ram and through a broken down gate and thereby eludes many of the arrows.

1 "Siege-Tower" that removes one of the 1-5 Wall-Archer rolls. Meaning that 1 Siege-Tower removes the Watch-Tower's single Wall-Archer. And 5 Siege-Towers remove a Capital's 5 Wall-Archers.

I have not been testing that much, but it seems to work fine.

[redrum]

@Frostion Excellent! Let me know if you find any issues and I can take a look but glad to hear its working as intended so far.

[Cernel]

@Frostion Siege-Towers usually have a battering ram at their base, integrated in the tower and protected by it.