Paratroopers and U-Boats

wc_sumpton

@beelee started a discussion about here where is was talking about how Paratroopers and U-Boats only gain support only during 1 combat round. Maybe supportAttachment could be round limited like AA attacks.

Cheers...

beelee

@wc_sumpton

yea there's some discussion on git about it here https://github.com/triplea-game/triplea/issues/12488

would be a cool feature

tripleabuilderbot created this issue in triplea-game/triplea

closed ConcurrentBattleCalculator#calculate:200 - java.lang.IllegalStateException #12488

wc_sumpton

@beelee

Understand, I read that and pulled part of your reply into the other thread.

If I understand the rules that you are referring to Paratroopers only receive their bonus support when they are only attacking alone, and only for 1 round of combat. That is why I don't think @Azimuth idea for using "whenHitPointsDamagedChangesInto" will work, because other attacking units need to be considered.

Rule quoted in question:
When Paratrooper units attack by air the attack
factor is “3” in the first round of combat.
From the second round of combat the attack
factor is “1”.
If Paratroopers attack by air and are supported by
units other than Paratroopers, the Paratroopers
attack at “1”.

So, when a Paratrooper attack only with other Paratroopers, they attack at 3, when supported by other units they attack at 1. This would require a self-support, plus a cancelation support from other units. Both would need max round limited to 1:

<attachment name="supportAttachmentParatrooperSelf" attachTo="Paratrooper" javaClass="UnitSupportAttachment" type="unitType">
  <option name="unitType" value="Paratrooper"/>
  <option name="faction" value="allied"/>
  <option name="side" value="offense"/>
  <option name="dice" value="strength"/>
  <option name="bonus" value="2"/>
  <option name="number" value="1"/>
  <!-- New option to check for rounds -->
  <option name="maxRounds" value="1"/>
  <option name="bonusType" value="ParatrooperSelfSupport"/>
  <option name="impArtTech" value="false"/>
</attachment>

Would this help?

Cheers...

beelee

@wc_sumpton so is "maxRounds" currently available ?

I had originally tried giving the a bonus with the AA shot and then any other units give a negative bonus for when they were together.

Problem was you got one AA roll at 2 on Attack and 1 on defense to go along with there regular rolls.

So yo got two rolls instead of one but the bigger issue is the AA hits can't fire back.

So I eventually removed it and just play it out in edit now.

wc_sumpton

@beelee said in Paratroopers and U-Boats:

@wc_sumpton so is "maxRounds" currently available ?

No, that is why I chose this topic.

Cheers...

wc_sumpton

@beelee

maxRoundsAA is already use for AA attacks, so checking the number of rounds for supportAttachment and territoryEffects should not pose that big of a problem. Also for unitAttachment. but with units, the owning player should be able to choose if these unit are retreated, or remain as fodder.

Cheers...

beelee

@wc_sumpton yea that's what i was thinking, but Idk if that would be easy to add to supportAttachments or if there are other factors that come into play making it more difficult/labor intensive

wc_sumpton

@beelee

supportAttachment gets added to the units prior to each round of battle. I have modified my version to create a new airRoll/airStrength to have the ability to support air units during air battles. So yes, I think adding a check for the combat round is not that hard. The same goes for territoryEffect, my engine code includes combatAADefenseEffect/combatAAOffenseEffect so that territoryEffect can modify AA special attacks (did these awhile ago when I was talking to @TheDog about GCD).

Having a "maxRounds" may be a little harder, but still seems kind of strait forward. The problem is what happens when a unit passes that round? Should it be retreated? Left for fodder? Give the player a choice? There's a lot there when talking about the unitAttachment.

Cheers...

Cernel

@wc_sumpton said in Paratroopers and U-Boats:

@beelee

supportAttachment gets added to the units prior to each round of battle. I have modified my version to create a new airRoll/airStrength to have the ability to support air units during air battles. So yes, I think adding a check for the combat round is not that hard. The same goes for territoryEffect, my engine code includes combatAADefenseEffect/combatAAOffenseEffect so that territoryEffect can modify AA special attacks (did these awhile ago when I was talking to @TheDog about GCD).

Having a "maxRounds" may be a little harder, but still seems kind of strait forward. The problem is what happens when a unit passes that round? Should it be retreated? Left for fodder? Give the player a choice? There's a lot there when talking about the unitAttachment.

Cheers...

Is there any intention of adding any of these features to the actual program?

I do believe artillery support should be round limited. It seems obvious enough unless you actually want to have ammunition consumption (which would limit it).

wc_sumpton

@beelee

This may give you some ideas for you wolfpack problem:

<attachment name="supportAttachmentSubSelfBuff" attachTo="submarine" javaClass="UnitSupportAttachment" type="unitType">
	<option name="unitType" value="submarine"/>
	<option name="faction" value="allied"/>
	<option name="side" value="offence"/>
	<option name="dice" value="strength"/>
	<option name="bonus" value="1"/>
	<option name="number" value="3"/>
	<option name="bonusType" value="selfBuff" count="3"/>
	<option name="impArtTech" value="false"/>
	<option name="players" value="Americans"/>
</attachment>
<attachment name="supportAttachmentSubSelfDebuff" attachTo="submarine" javaClass="UnitSupportAttachment" type="unitType">
	<option name="unitType" value="submarine"/>
	<option name="faction" value="allied"/>
	<option name="side" value="offence"/>
	<option name="dice" value="strength"/>
	<option name="bonus" value="-1"/>
	<option name="number" value="2"/>
	<option name="bonusType" value="selfDebuff" count="2"/>
	<option name="impArtTech" value="false"/>
	<option name="players" value="Americans"/> 
</attachment>

I think this may work as support is given 1 to 1. So, if there is only one sub it should buff itself once then debuff itself. With 2 subs should buff twice and debuff twice. With 3 or more (this buffing will not stop at 3) they should buff 3 times with only 2 debuff so the buff should apply.

Just some stupid thoughts.

Cheers...

beelee

@wc_sumpton

no there not stupid I had done something similar before, hmm ... so actually maybe it is kinda stupid lol

I think that'd work though. So, it'd keep boosting at 3 or more ?

Thing is, we only want it for 1st rd of combat, not whole battle.

I'm actually pretty pleased with how it's working. Just started a game today.

I screwed up and the wolfpack showup after NCM same as when they remove. Had to change to beforeEndTurn so they will show up after you place.

Plus the cool hepps image is badass lookin and makes for a quick visual to tell there's one there

Screenshot from 2024-05-02 21-30-15.png

I also had to change paratrooper from isAir to the same as the Para because the 2nd one can't land in newly conquered TTy.

That's ok though. They will place in any TTy you own, so just let em hook up with the Paras from the git go and move em all at once

beelee

@wc_sumpton

I remember now. originally i gave them a +2 one time AA shot on A and 1 on D for para, so it'd only last for one rd. But the hits can't fire back, which overpowered them.

They don't get the bonus unless by themselves, so i had to give a negative bonus to every unit that might be with them lol

That was overachievement ha ha ha But it kinda worked the way you wrote above

wc_sumpton

@beelee

Downloading and unpacking the game now. Will look it over to see if there is anything else stupid, I can think of.

Cheers...

beelee

@wc_sumpton Hey sweet ! If you got any better ideas for landmines, that's last big one.

Escorts i have so they'll place and replace for one escort. Gets too intense for anymore Majority place and remove that way anyway

wc_sumpton

@beelee

You have to many duplicate conditions:
At line 14982:

<attachment name="conditionAttachment_WolfpackRemoveInvert112" attachTo="Germans" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
  <option name="directPresenceTerritories" value="112 Sea Zone" count="1"/>
  <option name="unitPresence" value="GermanUBoat" count="3"/>
  <option name="invert" value="false"/>
</attachment>

Which is checking the presence of GermanUBoat in 112 Sea Zone for the Germans player. Then again at 15235:

<attachment name="conditionAttachment_WolfpackRemove112" attachTo="Germans" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
  <option name="directPresenceTerritories" value="112 Sea Zone" count="1"/>
  <option name="unitPresence" value="GermanUBoat" count="3"/>
  <option name="invert" value="true"/>
</attachment>

Their names may be different, but the conditions are the same.
The triggers at 45049 and 15292 can both reference the same condition, as the triggers have the 'when' option.

This duplication makes the xml much harder to read. Also you may think about using variableList and foreach to group things together. 78k lines makes for a very difficult read and I understand why you like 'leaving things as they are', because editing has become a time-consuming chore.

Cheers...

wc_sumpton

Psst... A little help for my friend. @beelee

To use variables and foreach, the variable lists must at the beginning of the xml. The standard location is right after diceSides but before map:

  <diceSides value="6"/>
  <variableList>
      <!-- Sea Zones used for Wolfpack buff checks -->
      <variable name="WolfpackSeaZones">
         <element name="127"/>
         <element name="126"/>
         <element name="125"/>
         ...
         ...
         ...
         <element name="82"/>
         <element name="81"/>
         <element name="80"/>
         <element name="70"/>
         <element name="69"/>
         <element name="68"/>
         <element name="67"/>
    </variable>
    <!-- Add more list as is necessary -->
  </variableList>
  <map>

Notice that I am only using the number part of the sea zones, " Sea Zone" can be added when needed! Now the triggers:

    <!-- 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>
	<!-- Place Wolfpack where there are 3 German U-Boats -->
    <attachment foreach="$WolfpackSeaZones$" name="triggerAttachment_Wolfpack_at@WolfpackSeaZones@_SeaZones" attachTo="Germans" javaClass="TriggerAttachment" type="player">
      <option name="conditions" value="conditionAttachment_3_GermanUBoat_@WolfpackSeaZones@_SeaZones"/>
      <option name="placement" value="@WolfpackSeaZones@ Sea Zone:Wolfpack" count="1"/> 
      <option name="when" value="before:germansEndTurn"/>
    </attachment>
	<!-- Remove Wolfpack prior to NonCombat move -->
    <attachment name="triggerAttachment_Remove_All_Wolfpack" attachTo="Germans" javaClass="TriggerAttachment" type="player">
      <option name="conditions" value="conditionAttachment_SwitchIsTrue"/>
      <!-- There are only 52 sea zones so using a count of 55 should get them all -->
      <option name="removeUnits" value="all:Wolfpack" count="55"/> 
      <option name="when" value="before:germansNonCombatMove"/>
    </attachment>
   <!-- end Wolfpack placement/removal -->

This should work, let me know what you think.

Cheers...

wc_sumpton

This topic should be moved Maps & Mods, I have created a new topic called Global 40 Expansion UHD Boxes, since this discussion centers mostly on that map.

Thank you!

Cheers...