@victoryfirst said in Air Battles Can Be Ignored:

Yeah so the air battle precedes the land battle but the prompt for ignoring land battles is shown after combat movement and before combat. So when the game asks you to fight in a territory and you click "no", no battle happens. I think it should be possible to extend this to air battles too, so I don't understand why the air battle preceding the land battle is a problem?

You are right! With the message coming prior to selecting the order in which to fight battles, it is quite easy to check for the preceding air battle and nix it also.

Wow who knew?

Cheers...

@thedog said in Review of "estimatedResourceProduction":

The property "Economic Victory"

This property only checks for ownership of a territory, it does not check for blockade, convoy, convoy routes, contested etc... (Something the engine calls "Can the territory produce?").

@thedog said in Review of "estimatedResourceProduction":

Also 1941 GCD industries produce PU each turn, so any units like Oil-Fields and Lend-Lease-Depots should also be taken into account, yes?

At this point "no". But I say this with caution, because getting this information is quite easy. It may require a new condition "territoryUnitProduction" created so it is not confusing.

Also triggers/objectives cannot be added because triggers/objectives could use the condition.

@beelee said in Review of "estimatedResourceProduction":

You doing just fine brother. We are who we are at this point. You get high marks from me

Thank you both.

Cheers...

@wc_sumpton

oh yea 😞

bummer

kinda doesn't make one want to help Be nice if someone would try and help with your work instead of just saying no.

idk maybe they do and I'm just reading it wrong.

You're good at what you do and more devs are always wanted.

idk not enough time for them to teach I guess 🙂

@cernel said in Allow income levels to be checked in conditions.:

However, it is good to have PUs as default if a resource is not specified.

Yes, this is how both conditions would/have been designed. "haveResources" is already set up in this manner. Whatever the other condition would be called would follow.

Cheers...

@cernel

No, just haven't resubmitted.

Cheers...

@cameron
Here is the code from 1941 GCD with a foreach all players

<!-- ======================================= GO isAI ======================================= --> <attachment foreach="$All-Players$" name="conditionAttachment_isAI_@All-Players@" attachTo="@All-Players@" javaClass="RulesAttachment" type="player"> <option name="isAI" value="true"/> </attachment>

There are lots of examples of its use, search the xml for

_isAI_

i'm not sure why you'd want air units to have diff stats over water vs land but if you did couldn't you just give water TTs a terrain effect that gives air units +/- ATT and/or DEF?

@lafayette

as far as I've seen in all the games and maps I've played, battle calc ALWAYS takes the hit from multi-hit units first no matter what and even with a casualty list order; unless there's some special casualty list order I'm unaware of that isn't listed on the description text.
I just verified the behavior by constructing a test case in the arda map with mordor 6 naz 6 pikemen attacking 12 gondor rangers on a forest in lowluck.

It's been that way for as long as I can remember; and it wouldn't have been unreasonable when first implemented since at that time it was the right choice for nearly all maps/situations.

@cameron said in units with multiple HP (Hit Points) heal fully:

... whether slowly healing is better or not ...

Personally, I like to take a bunch of roids and heal as fast as I can 🙂

Jam Tomorrow? 😜

@victoryfirst

Would be easy enough to do, there is a section of code in the engine that takes into account the type of unit, and blocks certain options based on the type, air, sea or land.

But as was done with "isStrategicBomber", which was blocked for land units, can cause side effects in the rest of the code.

There would need to be a discussion how to treat air units prior to allowing them "transportCost".

Cheers...

@cernel Thx for your advise.
I forwarded it here:
https://github.com/triplea-game/triplea/issues/12677

finally got this working. dunno what i did wrong the first time... sometimes you just need to delete it and start again. 😉

thanks for the help. 🙂

<attachment name="conditionAttachmentPlayerAT1" attachTo="Player" javaClass="RulesAttachment" type="player"> <option name="techs" value="ArmouredWarfare" count="1"/> </attachment> <attachment name="triggerAttachmentPlayer_NewTech" attachTo="Player" javaClass="TriggerAttachment" type="player"> <option name="conditions" value="conditionAttachmentPlayerAT1"/> <option name="availableTech" value="Advanced:MartianTechnology"/> <option name="uses" value="1"/> </attachment>

Ok, thank you.

@Panther could you please move this post to the Feature Requests & Ideas?

Here is my request:

Add to the current syntax of the tooltips.properties

tooltip.unit.fortress=Requires 3 hits to destroy

The option to define different tooltips for the same unit in different scenarios:

1941_Start_Date.tooltip.unit.fortress=Requires 3 hits to destroy 1942_Start_Date.tooltip.unit.fortress=Requires 3 hits to destroy<br/>Can be upgraded in MegaFortress

For my second request, I realized that it has already been suggested several times, for example here: https://forums.triplea-game.org/topic/421/add-unithelp-attribute

@beelee

This really depends on the type of 2-unit support.

Combined Arms support: Infantry, Armor and Fighter. Only when all 3 types of units are together will they receive a bonus.

<!-- Infantry Combined Arms --> <!-- Support given to all Armor and Fighters --> <attachment name="supportAttachmentInfantryCombinedArmsBuff" attachTo="Infantry" javaClass="UnitSupportAttachment" type="unitType"> <option name="unitType" value="Armor:Fighter"/> <option name="faction" value="allied"/> <option name="side" value="offence"/> <option name="dice" value="strength"/> <option name="bonus" value="1"/> <!-- Very high number is used because all unit can be buffed --> <option name="number" value="999"/> <!-- All Buffs need to have different names so that they can stack --> <option name="bonusType" value="InfantryCombinedArmsSupportBuff" count="1"/> <option name="impArtTech" value="false"/> <option name="players" value="Germans"/> </attachment> <!-- Infantry Combined Arms Debuff --> <attachment name="supportAttachmentInfantryCombinedArmsDebuff" attachTo="Infantry" javaClass="UnitSupportAttachment" type="unitType"> <option name="unitType" value="Armor:Fighter"/> <option name="faction" value="allied"/> <option name="side" value="offence"/> <option name="dice" value="strength"/> <option name="bonus" value="-1"/> <!-- Very high number is used because all unit can be buffed --> <option name="number" value="999"/> <!-- All Debuffs need to have the same name so that they cannot stack --> <option name="bonusType" value="CombinedArmsSupportBuff" count="1"/> <option name="impArtTech" value="false"/> <option name="players" value="Germans"/> </attachment>

Armor units have the same type, but only for Infantry and Fighters, and Fighters buff Infantry and Armor.

How this works: If only one unit type is in a territory, those unit do not self-buff, so there is no change to their attack. When two different unit types occupy the same territory, they will buff each other, but they also debuff each other, so there is no change to the attack value. But when all three types of units are together, each type will receive 2 buffs, but can only stack 1 debuff. So, each units attack value is increased by one.

Helpful?

Cheers...

@cernel said in Non isAir SBR Attacks, what should be done with them?:

@wc_sumpton said in Non isAir SBR Attacks, what should be done with them?:

another answer would be to restrict SBU usage to isAir units only.

I'm not seeing how this is an answer. Game-makers can already assure that if they want to, and (if I remember correctly) this would actually be a revert because there used to be this restriction in the past (which was deliberately dropped in order to allow land units to raid). I seem to remember this was done by @redrum (but I may be wrong).

Yes, I remember that. But allowing it and then requiring map makers to hack around the "retreat" problem only means that the process was not implemented properly/completely. Thus, restoring the block is still a valid option.

@cernel said in Non isAir SBR Attacks, what should be done with them?:

Can you please re-elaborate distinguishing between having and not having the property Retreating Units Remain In Place effective? Does setting that property true remove any of the issues without adding any other ones?

The same as "Attacker retreats", as in this case even the "retreated" non-isAir SBR units are all collected and remain or are moved to the retreat territory. So, there is no change and would has no effect when both attacker and defender units are all eliminated, or all attacker's forces are destroyed. The defender cannot win because of these "retreated" units.

When I say these units are "retreated", I saying as what it appears visually, this is not what happen within the game engine. The game engine marks the as completing a battle, so they cannot join another battle. Like a battleship which participates in a sea battle is marked so that it cannot bombard during an amphibious assault.

Cheers...

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

Yeah I mean I guess that's the drill.

Currently seems like tripleA is kinda FHD limited there. A smaller sized display with higher pixel density doesn't give many options right now. It's basically a choice between enlarged text/tables in the UI for readability, or a loss in graphical fidelity for anything that isn't font. I can make a map for a QHD, UHD, 4K whatever, but it's limited by what the UI can do there for scaling, and also for the unit graphics dimensions/upscale.

1080 is still around for sure, like that snowboard was definitely built to last hehe. I was playing BG3 in 1080 for a while, but for tripleA it isn't like trying to find a buttery smooth framerate for animations and cutscenes, but just sorta just updating the dimensions of those little tab windows I guess, to raise the roof beyond the 54px limit, or to get some better interpolation going on there. Currently the same graphics shown on the map will a lot cleaner, even when at the same scale/same image as the UI element (like in the stats bars, purchase screen, combat windows etc.) you can kinda do the side by side, to see where the pixelation is coming in.

For now recommended settings for tripleA would be HD/FHD with a display scale at 100% I guess. For the 2K jump still pretty beta, needs more elbow grease hehe

@jkprince interesting