Stack Unit Support

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>

ron-murhammer created this issue in triplea-game/triplea

closed Add count for support bonus type #5309

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

ron-murhammer created this issue in triplea-maps/the_pact_of_steel

closed Update supportAttachment count description #35

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.