ConcurrentBattleCalculator#calculate:200 - java.lang.IllegalStateException

[tripleabuilderbot]

Map

world_war_ii_global

Log Message

java.lang.IllegalStateException: Round 10,000 reached in a battle. Something must be wrong. Please report this to TripleA.
Territory: 62 Sea Zone Attacker: Japanese Attacking unit types: carrier,battleship,fighter,transport,destroyer,cruiser, Defending unit types: carrier,battleship,submarine,fighter,destroyer,cruiser

TripleA Version

2.6.14470

Java Version

11.0.4

Operating System

Windows 10

Stack Trace

Exception: java.lang.IllegalStateException java.lang.IllegalStateException: Round 10,000 reached in a battle. Something must be wrong. Please report this to TripleA.
 Territory: 62 Sea Zone Attacker: Japanese Attacking unit types: carrier,battleship,fighter,transport,destroyer,cruiser, Defending unit types: carrier,battleship,submarine,fighter,destroyer,cruiser
java.lang.Exception
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateParallel(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)
	at java.base/java.util.stream.ReferencePipeline.collect(Unknown Source)
	at games.strategy.triplea.odds.calculator.ConcurrentBattleCalculator.calculate(ConcurrentBattleCalculator.java:200)
	at games.strategy.triplea.odds.calculator.BattleCalculatorPanel.lambda$updateStats$13(BattleCalculatorPanel.java:1173)
	at java.base/java.lang.Thread.run(Unknown Source)


Exception: java.lang.IllegalStateException Round 10,000 reached in a battle. Something must be wrong. Please report this to TripleA.
 Territory: 62 Sea Zone Attacker: Japanese Attacking unit types: carrier,battleship,fighter,transport,destroyer,cruiser, Defending unit types: carrier,battleship,submarine,fighter,destroyer,cruiser
java.lang.Exception
	at games.strategy.triplea.delegate.battle.MustFightBattle$29.execute(MustFightBattle.java:1344)
	at games.strategy.triplea.delegate.ExecutionStack.execute(ExecutionStack.java:34)
	at games.strategy.triplea.delegate.battle.MustFightBattle.fight(MustFightBattle.java:714)
	at games.strategy.triplea.odds.calculator.BattleCalculator.calculate(BattleCalculator.java:115)
	at games.strategy.triplea.odds.calculator.ConcurrentBattleCalculator.lambda$calculate$4(ConcurrentBattleCalculator.java:188)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
	at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
	at java.base/java.util.stream.ReduceOps$ReduceTask.doLeaf(Unknown Source)
	at java.base/java.util.stream.ReduceOps$ReduceTask.doLeaf(Unknown Source)
	at java.base/java.util.stream.AbstractTask.compute(Unknown Source)
	at java.base/java.util.concurrent.CountedCompleter.exec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)

[beelee1]

hmm .. havent seen this in 2.6 Maybe try the latest 2.6 It might be already fixed

[fasthard]

Thx for your answer, but isn't 2.6.14470 the latest 2.6 version?

[beelee1]

@fasthard looks as if 14705 is latest. https://github.com/triplea-game/triplea/releases/

I've been using 14696 and haven't noticed it. It may have just not come up yet though. Looked like when same units went at it is when it nutted up. So that's possible it's not known about and still going on.

[asvitkine]

@fasthard do you remember what happened when you got this error? Do you happen to have an autosave from a phase right before this that reproduces the error after loading?

We've gotten a few reports of this type of error, but not a reliable way to reproduce, so any help would be appreciated!

[fasthard]

Hi, well I edited this file:
rus006.zip
to this file:
BM4_O&EvsA+22_US7_.zip
Thanks for you effort!

[asvitkine]

@fasthard

Those two saves have all players set to human and there are no pending combat moves. So it doesn't seem like there's enough to reproduce the issue there?

Can you clarify again how you got the error? Were you playing this game online with a bunch of humans - or did you play with AIs? You don't have any autosaves from right before the bug happened?

[asvitkine]

Although I guess I can reproduce this by just leaving edit mode on when ending a phase.
Here's a repro:

autosaveBeforeEndTurn.tsvg.zip

I guess we can make it so ending a phase will turn off edit mode. Or we can make it so no combats happen in edit mode.

[asvitkine]

Looks like the error is not new to 2.6. I tried with 2.5 and hit this one: #12434

[asvitkine]

I looked through at the code history of when edit mode was made to ignore combat casualties and it was when it was originally added here:
ab56e9c

So I guess it always worked this way (i.e. no casualties are done when edit mode is active in combat). I'm actually not sure why that's the case. To me, edit mode is just about editing the state of the game. I feel like after you do that, there's no reason to also make combat dice rolls have no effect - why not let it happen as normal?

That would simplify the code a lot and let us get rid of bugs like these.

[beelee1]

@asvitkine

yea, so the G 40 Expansion mod uses edit with no casualties being selected so it can produce the desired game result that triplea can't do otherwise.

For example, there are units that get a +1 on 1st rd of attack or defense and then revert to there normal combat modes. The only way I can make it work, is to play the battle in edit and pick the casualties manually. They still show as a hit or not according to there combat values but don't auto hit.

If you make it so they auto hit, it will require a mass amount of edit to use and since the dice roller isn't documented, which would be a slower process, one would have to use an outside dice roller for verification.

Please don't change this behavior or maybe I have misunderstood what was being discussed

Edit
yes i have encountered errors while in edit mode several times, but simply alerting the player that they shouldn't be in edit and they won't get the error should be a sufficient solution.

Being able to select casualties manually, same as you would playing in person, offers a lot of flexibility. Obviously, it's not ideal, but if not available it will limit ways to play that have rules that triplea can't do.

[Cernelius]

So I guess it always worked this way (i.e. no casualties are done when edit mode is active in combat). I'm actually not sure why that's the case. To me, edit mode is just about editing the state of the game. I feel like after you do that, there's no reason to also make combat dice rolls have no effect - why not let it happen as normal?

I don't think so. I remember that in the past having Edit Mode selected just allowed you to take whatever casualties you wanted (comprising possibly none at all), then (many years ago) the behaviour changed to everyone being immortal with Edit Mode on.

I guess it was not an intended change, but I think I've never reported it.

It was many years ago when this happened, so I might be remembering wrong, but I'm almost sure of what I'm saying.

[asvitkine]

@beelee1

Interesting. Can you give more details about how selecting casualties manually works in edit mode? From what I can tell (before my change) is it would just default to no units taking damage, but the dialog to select which ones to take as casualties still pops up.

Do you mean that you still play through the combat, but after each roll of dice, you go back to the map and delete units (and that affects the running battle)? Or is there some way to do this from the combat UI?

Seems like a pretty cumbersome use case. Perhaps we can just support whatever rules "G 40 Expansion" required natively in the engine? Are there any maps where people need to do this?

[beelee1]

@asvitkine yea so here's how I currently do it on 2.6 14705 Just a quick hack to show it. If there are 3 Submarines, they get A1 D1 for first rd of combat only. Then they get there normal combat values of A2 D1. Here are some shots

so we have 3 U-boats attacking. When there are 3 they get a +1 attack for first rd only. So i use edit to be able to pick the casualties as needed.

so no hits in this case as a 4 and two sixes are rolled.

this is what shows up in the battle window. The hits are currently zero but I can pick as many as I want.

That way, if there was a hit at 3 in the first rd I could select it.

Hmm I don't think I explained it very well. Basically you can choose to take a hit or not

[beelee1]

@asvitkine yea it's not ideal play wise but only way to be rule compliant with this mod :) It's actually just part of game play at this point as were on game 4 using it.

I'm not entirely sure I'm understanding your change. I haven't tried it yet. On 14705

[beelee1]

@asvitkine I had forgotten your question

And on page 8, it's talking about Tank Armies and Army Corps which sound like they might be changing the number of dice rolled, etc. Wouldn't that not be supported with how Edit mode combat works due to number of dice differences?

Yea the extra rolls show up in edit. So it works correctly.

Yea Paratroopers will work with no edit now. This can probably be closed. wc has opened a feature request at the site https://forums.triplea-game.org/topic/3797/paratroopers-and-u-boats

It'd still be nice to have at some point in the future. A lot easier to work with and other maps might use it differently.

And still keep edit as is. There are other situations it's still needed. The flexibility it provides is a great tool for non rule compliant games.

Anyway, Thanks again for your help.

[WCSumpton]

@beelee1
You've created a condition to check every territory for paratroopers. Then created another condition to check every territory for the absence of allied units, except aaGuns. Created a trigger for every territory that checks those conditions to spawn a suicide unit to give a bonus for a single combat round. That's a wild hack! Way to go. LOL

Cheers...

[beelee1]

@WCSumpton heh heh not that hardcore :) What I did was add a "ParatrooperBoost" unit that gives the support. He's "isAir" with 99 movement, so can go anywhere.
There are two place phases. So you need to buy as many as you need at no cost and then place in 1st place phase. That way there ready for combat that turn.

It's essentially Player Enforced. If you forget to buy one or not enough, need to edit one in at start of CM. They are "isConstruction" so they don't count as a placement.

You'll have to edit them in for defense after the battle if you win. I have some extra boxes too and have thought about just at top of map I could store some in. Then you could just click on them in NCM and "Perform Move or Other Actions" . Might be a little easier than adding by hand. Edit Or just by a extra one at start. Leave him in your Capital. That'd be easy enough :)

Still have to hand roll for any AA fire they encounter as the defender can choose his targets if normal Air Units attack with it. Otherwise I could make a special aaGun to shoot at just the Paratroopers. I suppose I could make one trhat only shoots once and you can edit those in for the defender as needed.
Idk, it's not to bad to hand roll. Too bad Dice Roller wasn't documented in History :) We just use the A&A.org one for our PBF games.

The Wolfpack is the one I went big on :) But I already had that done for removing the Wolfpack if there were less than 3 U-boats. Just for Atlantic and Med. So I just copied it and changed that for it to add a Wolfpack when theres 3 or more :)

A little edit still but a Major improvement :)

[asvitkine]

So assuming we want to keep edit as-is, how to resolve the 10000 rounds error?

For battle simulation (that AI does behind the scenes), it's easy enough to just turn edit off for the simulations.
But then you get real AI battles - and those will just freeze triplea as it will actually try to go for that many rounds.

At first, I thought we could make AI retreat, but then that's not always an option.
I guess the question is who should be selecting casualties in edit mode in that case? If it's AI vs. AI, I guess we could just make casualties be selected as if it's not auto. But theoretically if it's an AI vs. human or human vs. AI battle, you do want casualties selected manually?

[asvitkine]

I think for now, I'll just make edit mode get turned off when transitioning to an AI player step. Before the change, that would have just hit that error anyway, so now at least it won't.

[asvitkine]

@beelee1

I have another idea of how to make subs work as you want them. Same idea of spawning a special unit before attack phase whenever there are groups of three subs of the current player.

Make this unit suicide and make it actually have attacking rolls that the subs should have on first round. Then make its support attachment negatively affect the three subs by removing their dice rolls or changing what they hit on to 0.

I think that should work. Could you try it out?

[beelee1]

@asvitkine

Yea Idk about player vs AI in edit. I would think that wouldn't work. Never tried it. I think edit would require a human to use it.

I'm actually quite pleased with how things are working now. Just a HUGE improvement thaks to your suggestion :) I like the support unit, because we can use hepps badass looking unit image, which helps tell at a glance that there is a wolfpack formed.

I will test out your latest idea though.

Thanks again. Really a Major improvement, with both it and paratroopers

[beelee1]

@asvitkine

just reread. Yea, I see what you're saying now. The result would be the same, just a different way todo it. But I will test it

[beelee1]

@asvitkine

Using your last suggestion I get an extra roll in combat. 3 U-boats and 1 Wolfpack get 4 rolls. Maybe I have the supportAttachment written wrong.

The negative bonus so the U-boats don't fire works correctly.

I tried it with 4 U-boats and got 5 dice. The Wolfpack is now A3 D3 and kills itself on both attack and defense.

Anyway, your original suggestion works great :) And revisiting this has made me realize I should try and have the Wolfpack spawn end of CombatTurn. Won't need to buy and place at all then :)
I can also duplicate the triggers and have them respawn after place as well.

[asvitkine]

@beelee1

Is the Wolfpack the unit that's spawned when there are three u-boats? Then the support attachment isn't set up how I expected.

I would expect it to be attached to Wolfpack and not GermanUBoat and for it to have unitType be GermanUBoat. So you want the Wolfpack affecting the UBoats, not the other way around.

Then you want number to be set to 3 to affect 3 uboats. And you set <option name='dice' value='strength'/> and <option name='bonus' value='-1'/> to blank out their rolls.

[WCSumpton]

@beelee1, @asvitkine

Right now, the global_40_expansion_uhd_boxes.xml is over 78k lines long and makes for a difficult read. Every 'work-around'/hack only make editing more difficult. It's no wonder @beelee1 would rather leave thing 'as they are'. Even though the hacks look good here, each sea zone for subs, escorts, transports, etc. must be check 3 or 4 times per sea zone and there are 127 sea zones to check, and these checks are multiplied by each player. Without the use of variables and foreach loops, the number or xml lines just continues to increase.

Again, I suggest that adding "maxRounds" check to both supportAttachments and territoryEffectAttachments would be a better route for what @beelee1 wants to accomplish.

Cheers...

[beelee1]

@asvitkine

I would expect it to be attached to Wolfpack and not GermanUBoat and for it to have unitType be GermanUBoat. So you want the Wolfpack affecting the UBoats, not the other way around.

yea that's how I set it up the first time, which works. I was just trying your new idea because you asked me to. I don't really see the difference result wise.

The Wolfpack boosts the U-boats +1 for 1 rd in the first way. The second way the U-boats boost the Wolfpack for 1 rd with the Wolfpack taking away the U-boat 1st rd combat to 0.

The first way works good, so i'll just roll with that :)

@WCSumpton
yea it's pretty messy lol. I need to revisit the variables thing and try and clean it up. My past attempts have all failed :)

[asvitkine]

@asvitkine

I would expect it to be attached to Wolfpack and not GermanUBoat and for it to have unitType be GermanUBoat. So you want the Wolfpack affecting the UBoats, not the other way around.

yea that's how I set it up the first time, which works.

I thought it didn't work on attack because a suicide unit dies before it can provide support? Or did I misunderstand.
I was trying to find a suggestion to workaround that.

I was just trying your new idea because you asked me to. I don't really see the difference result wise.

I think there was a miscommunication since my new idea was still having the special unit to provide support. It was meant to workaround it not working on attack due to the suicide thing - but maybe I didn't understand and it actually works already?

Again, I suggest that adding "maxRounds" check to both supportAttachments and territoryEffectAttachments would be a better route for what @beelee1 wants to accomplish.

Doesn't that still require the map script creating the support unit (which I think is the main part of the complexity)? I don't see it being different in terms of complexity of XML between the two solutions except adding that property requires coding engine changes (and a lot of complexity) whereas the idea behind my suggestion is existing features can already accomplish the task.

... And yeah if you want to do checks per-sea zone etc, that should be done with variables. If it's not doing that, that would be the first thing to clean up. (Just define a list of sea zones at the top of the file and do foreach on them.)

Also, just in terms of reducing file size, you can remove everything except the last name for all the javaClass= properties - i.e. javaClass="UnitSupportAttachment" instead of the very long thing. Same for every other attachment type.

[asvitkine]

Also, just in terms of reducing file size, you can remove everything except the last name for all the javaClass= properties - i.e. javaClass="UnitSupportAttachment" instead of the very long thing. Same for every other attachment type.

I sent a PR for that here: triplea-maps/global_40_expansion_uhd_boxes#4

[WCSumpton]

Doesn't that still require the map script creating the support unit (which I think is the main part of the complexity)? I don't see it being different in terms of complexity of XML between the two solutions except adding that property requires coding engine changes (and a lot of complexity) whereas the idea behind my suggestion is existing features can already accomplish the task.

No, the GermanUBoat would apply the buff itself and there would be no need for a separate Wolfpack unit. If there was a "maxRounds" option in support attachments then:

    <attachment name="supportAttachmentWolfpackBuff" attachTo="GermanUBoat" javaClass="UnitSupportAttachment" type="unitType">
      <option name="unitType" value="GermanUBoat"/>
      <option name="faction" value="allied"/>
      <option name="side" value="offence"/>
      <option name="dice" value="strength"/>
      <option name="maxRounds" value="1"/>
      <option name="bonus" value="1"/>
      <option name="number" value="3"/>
      <option name="bonusType" value="Wolfpack_bonus" count="3"/>
      <option name="impArtTech" value="false"/>
      <option name="players" value="Germans"/>
    </attachment>
    <attachment name="supportAttachmentWolfpackDeBuff" attachTo="GermanUBoat" javaClass="UnitSupportAttachment" type="unitType">
      <option name="unitType" value="GermanUBoat"/>
      <option name="faction" value="allied"/>
      <option name="side" value="offence"/>
      <option name="dice" value="strength"/>
      <option name="maxRounds" value="1"/>
      <option name="bonus" value="-1"/>
      <option name="number" value="2"/>
      <option name="bonusType" value="Wolfpack_Debuff" count="2"/>
      <option name="impArtTech" value="false"/>
      <option name="players" value="Germans"/>
    </attachment>

Is all the code needed to handle the attack support. It's like "maxRoundsAA", which govern how may rounds a unit may conduct an AA attack.

Cheers...

[beelee1]

@asvitkine

yea muts've been a Led Zeppelin breakdown. :)
Your first solution works great.

I will look at the suggestions to clean up the code.

@WCSumpton

yea still wanna have the Wolfpack image show up thow, which is easy enough todo with conditions.

Anyway, it's working real good right now. I just changed it so the Wolfpacks place or remove before combat. Also after place. For placement, so if you buty 3 and place, then it'll spawn as well.

Only time we'd need to edit is if the Wolfpack disolved in defense.
Like USA attacks, kills a U-boat and then UK attacks right after. If there were still 3 or more Wolfpacks left after the USA attack, you'd have to edit the Wolfpack back in since he'd be dead from the combat.

Anyway, I don't wanna bug on your guy's time. It's working real good right now.

Thanks for all your help :)

[beelee1]

@WCSumpton

Actually your suggestion is the best, because if the U-boats were attacked during another players turn and still had at leat 3 present, the behavior would be correct.

The image would be gone, but bfd it'll respawn :)

[WCSumpton]

@beelee1

Let's take a second to look at what @asvitkine is suggesting. First you would need to create variable list or all the sea zones:

<variableList>
   <!-- A list of all Atlantic/Mediterranean sea zones to check for Walfpack -->
   <!-- There are 52 sea zones to check -->
   <variable name="WolfpackSeaZones">
      <!-- All sea zones end in " Sea Zone" so only the number is set -->
      <element name="127"/>
      <element name="126"/>
      ...
      ...
      ...
      <element name="68"/>
      <element name="67"/>
   </variable>
</variableList>

Now for some conditions:

<!-- Check for the presence of 3 German U-Boats -->
<attachment foreach="$WolfpackSeaZones$" name="conditionAttachment_3_GermanUBoat_@WolfpackSeaZones@_SeaZones" attachTo="Germans" javaClass="RulesAttachment" type="player">
   <option name="directPresenceTerritories" value="@WolfpackSeaZones@ Sea Zone" count="1"/>
   <option name="unitPresence" value="GermanUBoat" count="3"/>
</attachment>
<!-- Also check for the presence of any other friendly unit -->
<!-- This should check for all sea and air unit that can aid -->
<attachment foreach="$WolfpackSeaZones$" name="conditionAttachment_No_Allied_Help_@WolfpackSeaZones@_SeaZones" attachTo="Germans" javaClass="RulesAttachment" type="player">
   <option name="directPresenceTerritories" value="@WolfpackSeaZones@ Sea Zone" count="1"/>
   <option name="unitPresence" value="Battleship:Destroyer:every thing but Transport:and all air" count="1"/>
   <option name="invert" value="true"/>
</attachment>

Next are the triggers:

<!-- Place Wolfpack where there are 3 German U-Boats with no allied help -->
<attachment foreach="$WolfpackSeaZones$" name="triggerAttachment_Wolfpack_at@WolfpackSeaZones@_SeaZones" attachTo="Germans" javaClass="TriggerAttachment" type="player">
      <option name="conditions" value="conditionAttachment_3_GermanUBoat_@WolfpackSeaZones@_SeaZones:conditionAttachment_No_Allied_Help_@WolfpackSeaZones@_SeaZones"/>
      <option name="placement" value="@WolfpackSeaZones@ Sea Zone:Wolfpack" count="1"/> 
      <option name="when" value="after:germansCombatMove"/>
      <!-- These are added to ensure Wolfpack is placed for defensive purposes -->
      <option name="when" value="after:russiansCombatMove"/>
      <option name="when" value="after:americansCombatMove"/>
      <option name="when" value="after:chineseCombatMove"/>
      <option name="when" value="after:britishCombatMove"/>
      <option name="when" value="after:anzacCombatMove"/>
      <option name="when" value="after:frenchCombatMove"/>
    </attachment>
    <!-- Remove Wolfpack prior to NonCombat move (There was no check for enemy units) -->
    <attachment name="triggerAttachment_Remove_All_Wolfpack" attachTo="Germans" javaClass="TriggerAttachment" type="player">
      <option name="conditions" value="conditionAttachment_SwitchIsTrue"/>
      <!-- There are 52 sea zones, so 55 gives a little cushion -->
      <option name="removeUnits" value="all:Wolfpack" count="55"/> 
      <option name="when" value="before:germansNonCombatMove"/>
      <option name="when" value="before:russiansNonCombatMove"/>
      <option name="when" value="before:americansNonCombatMove"/>
      <option name="when" value="before:chineseNonCombatMove"/>
      <option name="when" value="before:britishNonCombatMove"/>
      <option name="when" value="before:anzacNonCombatMove"/>
      <option name="when" value="before:frenchNonCombatMove"/>
    </attachment>

If this seems easier, then there you have it!

Cheers...

[beelee1]

@WCSumpton

Oh way sweet you taking time on this. :)

I'll look closer tommorow as it's getting late in the day for me :)

But yea, i need to get that variable shit to work lol

[asvitkine]

@WCSumpton

No, the GermanUBoat would apply the buff itself and there would be no need for a separate Wolfpack unit. If there was a "maxRounds" option in support attachments then:

I'm not really following how this works, do you mind explaining? How does it ensure that the bonus only applies when there are three units present?

I see you're using count on bonusType, but I don't see how that helps here, from the docs:

Can use count (defaults to 1) to stack the same bonusType on a single unit like <option name="bonusType" 
value="ArtStackBonus" count="3"/> where a unit could receive up to 3 units supporting it of that bonusType.
Any support of the same bonusType MUST have the same count.

[WCSumpton]

@asvitkine

A unit can give a support to the supported unit once
A unit can give multiple supports to the same unit as long as each support is named differently
GermanUBoats can apply a +1 bonus to 3 (number) GermanUBoats and that bonus can stack 3 times (count for bonusType Wolfpack_bonus). It can also apply a -1 bonus to 2 GermanUBoats that can only stack twice.
1 GermanUBoat attacks at 2 +1 Wolfpack_bonus -1 Wolfpack_Debuff = 2 Attack
2 GermanUBoats attacks at 2 +2 Wolfpack_bonus -2 Wolfpack_Debuff = 2 Attack each
3 GermanUBoats attacks at 2 +3 Wolfpack_bonus -2 Wolfpack_Debuff = 3 Attack each

Hope this explains what I am talking about.

Cheers...

[Cernelius]

Beside that the "number" of the second attachment should be 3 too, have you tested it (asking because I haven't)?

To make a simpler example, are you sure that, when there is a unit which can give support to 3 other units and each of these units can receive up to 3 supports of that type, each of the units are supported once instead of only one of the units being supported thrice?

I agree that should be the behaviour (and I suggest to change it to that if it is not), but I remember that I argued about it with @ron-murhammer, and I remember that he instead decided to go for stacking supports on the same unit as much as possible before supporting more as a behaviour.

Again, I've not tested this specifically, and it was years ago, so I may be remembering wrong.

[WCSumpton]

@Cernelius

I have tested this. Also, every unit added will receive that 'last bonus'. So, even though the bonus stopes at 3, adding a fourth unit and all 4 unit will attack at 3. As to the debuff, stack count is 2, and it is the same unit, so the number does not matter as long as it is equal or greater than the stack count.

Cheers...

[WCSumpton]

@Cernelius

That is what I said, the "number" does not matter as long as it is equal to or greater than the stack count. 2, 3, 4 they work because it is the unit debuffing itself, so the addition of another unit only adds to the stack count not the "number" of unit affected. Funny things will happen if the "number" is less than the stack count. LOL

Cheers...

[Cernelius]

Yes, I see it now, and anyway you tested it so most likely all good.

Still, if what I remember from years ago is correct, that would mean that, when a single unit can support multiple units each of which can be supported multiple times by that same type of support, the behaviour is never to support any same unit more than once even if that means wasting the exceeding supporting modifiers, whereas, when each of multiple units can support a single unit, the behaviour is to support a same unit as much as possible before supporting more units. Am I right (Still have not tested it yet.)? If so, that seems somewhat inconsistent to me, but I need to get around doing some testing about it and maybe opening a discussion or an issue about it.

---

Anyway, since you tested it that it works that way, I definitely agree that having a "maxRounds" is all that it is needed, and doing it that way is way better and cleaner. On top of that, a "maxRounds" would be a very valuable feature on its own.

[Cernelius]

It is also an interesting albeit rough example of sort of "economies of scale" (not the right phrase), where having more submarines in the same zone makes each of them more effective.

It makes me think to some cards of "Magic" where the offence/defence (or whatever it is called) of each of the cards is equal to the number of these cards in play.

In TripleA terms, it would be like that, if you have 1 unit in the battle, the unit is 1/1, if you have 2 units in the battle, each of the units is 2/2, if you have 3 units in the battle, each of the units is 3/3, and so on.