Fast Battle Calculator

RaiNova

Why does the battle calculator make a copy [of the game in memory] of the game save data in the first place?

@Cernel [...] My best guess is that nobody bothered making it efficient because, as long as you only play the basic games or such, it is virtually timeless anyway (unless maybe in case you play for hundreds of rounds, which virtually never happens). I believe that currently the game which suffers the most from it is "270BC Wars": I have to wait about 6 seconds for the battle-calculator to become usable.

I have experienced that in 270bc wars, too. I believe I can fix this. Any other thoughts about a fast battle calculator? It bothers me in other games, too, e.g. a song of ice and fire.

Cernel

@rainova For fastening the use of the battle-calculator, the ability to click to calculate while the battle-calculator is loading the data, so that, as soon as the data is loaded, the battle-calculator starts calculating, thereby eliminating the dead-time that currently elapses between the battle-calculator having finished loading the data and you actually clicking to start calculating (as well as the need of keeping looking at the battle-calculator waiting for the button to become available for clicking). But I guess this would be a moot point if loading the data is rendered almost instantaneous. Practically, clicking to battle-calculate while you cannot yet (because the data is still loading) would mean telling the program you want to battle-calculate as soon as possible. In any case, once you have clicked on the button until the battle-calculations stop, you must be impeded interacting with it any further (not changing units numbers and such).

Since nothing can change what matters for the battle-calculator during the same phase beside a trigger firing (which, during the phase, can happen only during the user-action phase) or you adding or removing technologies or units with edit mode, having the data cached (and loaded from the cache if the battle-calculator is thereafter closed and re-opened or more battle-calculator instances are opened) since you firstly opened the battle-calculator during any phase until one or more of the following happen (clearing the data from the cache):

The phase ends.
A trigger fires successfully (only for user-action phases).
A technology is added or removed with edit mode.
A unit is added or removed with edit mode.

Alternatively to the last two points, to keep it simpler, you can have the cache cleaned as soon as edit mode is enabled and no cache-storing available for the battle-calculator while edit mode is kept on.

I believe changing political relationships should have no effect at all on what you can battle-calculate (as I believe you should be able to battle-calculate against allies which are not part of your alliance). However, if this is not actually the case, the following cache clearing phase should be added:

A relationship is changed (either with a political action or with a trigger fired via user-action or with edit mode).

Cernel

@cernel said in Fast Battle Calculator:

Alternatively to the last two points, to keep it simpler, you can have the cache cleaned as soon as edit mode is enabled and no cache-storing available for the battle-calculator while edit mode is kept on.

Actually, I think it should be done this way, as potentially edit mode could be anytime expanded to be able to change whatever on the board and wherever else in the game, so better making sure that everything is re-checked as soon as edit mode is turned off regardless, to avoid the risk that future changes to the edit mode function may conflict with the handling of the battle-calculator.

RaiNova

@cernel Caching is part of the concept. My current state of development doesn't cache the final result, but an intermediary calculation step. This way the calculator stays sensitive to changes. Until I run into problems, you can leave such technicalities with me (and other developers). The most important input I need is

a) UI integration (thanks for your contributions already!)
b) functionality requests
c) rule clarifications (I will come up with specific questions)

RaiNova

I have an idea how to handle whenHitPointsDamagedChangesInto if the new unit is infrastucture (as it is the case in 270B). Are there any games, where a damaged unit changes into a non-instrastructure unit?

beelee

@rainova yea there are a few. Total World War uses it. I use it for Global 40 expansion. I know there are some others also.

RaiNova

Is isRocket relevant for battle?

beelee

@rainova Idk. I wouldn't think so. It's used for attacking infrastructure and there is no "Air Battle".

Cernel

@rainova No.

RaiNova

@LaFayette Happy new year! I'd like to submit a first draft of a PR for the fast battle calculator. It's intended for version 2.7 (or 3.0). How can I submit a PR for 2.7/3.0?

RaiNova

@Cernel Look's like my battle calculator will be able to handle 99.99% of all BC270 battles (probably everything with armies smaller than 256 units on one side ). I'll keep the functional discussion in this forum and leave github for technical issues (like naming classes).

Here are some questions:

I suggest keeping the current battle-calculator beside this new one [...]

Is this in order to be able to validate the new calculator's results or would you like to choose to get some randomness in your results when you feel like it? The latter makes no sense to me.

(The new calculator will probably not cover every battle, so as a backup for such battles, the current calculator will remain.)

I am starting to work on the BC270 artillery. Could you (or anybody else) point me to a precise description of all the relevant attributes resp. write/publish something? I found nothing about offensiveAttackAAmaxDieSides for example.
I have difficulties working it out from the code, because of the heavy use of Lombok (and because I was really a C++ programmer back then (i.e. at the turn of the millenia) and now I a much more comfortable with Kotlin than with Java). Given the success of TripleA and the power of all those attributes, the docu deserves an upgrade anyway IMHO.

In 270BC_Wars.xml you define an option AttackAA. Shouldn't it be attackAA?

beelee

@rainova said in Fast Battle Calculator:

I found nothing about offensiveAttackAAmaxDieSides for example.

This is from Pact Of Steel 2 xml

attackAA values: the value that an isAA unit will attack at, for shooting at air units before battle

	attackAAmaxDieSides					values: sets the dice sides for aa guns.  defaults to whatever you chose above in diceSides (or 6 if you didn't choose).  All units with the same typeAA must have the same dice sides.
													Be Warned that all aa attack values (including with Radar and without Radar), MUST divide into attackAAmaxDieSides without remainders, or else there WILL be errors in LowLuck!

	offensiveAttackAA 					values: same as attackAA but for offensive side

	offensiveAttackAAmaxDieSides 		values: same as attackAAmaxDieSides but for offensive side

pact_of_steel_2.xml

Cernel

@rainova said in Fast Battle Calculator:

@Cernel Look's like my battle calculator will be able to handle 99.99% of all BC270 battles (probably everything with armies smaller than 256 units on one side ).

Please be sure to clarify whether you are talking about "270BC" or about "270BC Wars": they are very different games. In "270BC" is not rare to have a side having over 200 units in a battle, whereas in "270BC Wars" that is almost impossible (because stacks are much smaller in "270BC Wars", compared to "270BC").

I'll keep the functional discussion in this forum and leave github for technical issues (like naming classes).

Seems a good way to go.

Here are some questions:

I suggest keeping the current battle-calculator beside this new one [...]

Is this in order to be able to validate the new calculator's results or would you like to choose to get some randomness in your results when you feel like it? The latter makes no sense to me.

Even if you would cover everything, I'm not sure there may be problems now, and I think there is at least a chance something in the future may be not supported properly or at all.
Moreover, I think it is better that any developer adding a new feature which may impact on the battle-calculator is not demanded to update the battle-calculator too.

Besides, are you excluding that (at least for low enough run-counts) the current battle calculator may be faster than the new one in some cases?

(The new calculator will probably not cover every battle, so as a backup for such battles, the current calculator will remain.)

Maybe hiding the current if the program detects that every battle is fully covered for the currently selected game may be good, but I would also add an option in Engine Preferences for having it always.

I am starting to work on the BC270 artillery.

Unfortunately, the "270BC Wars" artillery has the issue that it gets taken as casualty or removed too soon, because the autoselector doesn't see it (so an offence/defence 0/0 unit with some powerful AA ability is just seen as powerless). Reliable results can only be obtained using "Order of Losses".

Could you (or anybody else) point me to a precise description of all the relevant attributes resp. write/publish something?

Are you aware that the main official TripleA documentation on game file coding is
https://github.com/triplea-maps/the_pact_of_steel/blob/master/map/games/pact_of_steel_2.xml
?

I found nothing about offensiveAttackAAmaxDieSides for example.

Read
https://github.com/triplea-maps/the_pact_of_steel/blob/be0efc7042287dd24a2bbb57e5bc01f4fe4fe5d7/map/games/pact_of_steel_2.xml#L1933
and
https://github.com/triplea-maps/the_pact_of_steel/blob/be0efc7042287dd24a2bbb57e5bc01f4fe4fe5d7/map/games/pact_of_steel_2.xml#L1930

I have difficulties working it out from the code, because of the heavy use of Lombok (and because I was really a C++ programmer back then (i.e. at the turn of the millenia) and now I a much more comfortable with Kotlin than with Java). Given the success of TripleA and the power of all those attributes, the docu deserves an upgrade anyway IMHO.

I'm not sure what "docu" you are referring to.

In 270BC_Wars.xml you define an option AttackAA. Shouldn't it be attackAA?

All occurrences of "AttackAA" and "AttackAAmaxDieSides" should be, respectively, "attackAA" and "attackAAmaxDieSides".
However, I'm not aware such wrong casing has any actual negative consequences. Has it?
Unfortunately, I don't believe TripleA offers anything to check for such cases, so I think that they are widespread across games.

RaiNova

@cernel said in Fast Battle Calculator:

Please be sure to clarify whether you are talking about "270BC" or about "270BC Wars": they are very different games.

I meant "270BC Wars".

In "270BC" is not rare to have a side having over 200 units in a battle, whereas in "270BC Wars" that is almost impossible (because stacks are much smaller in "270BC Wars", compared to "270BC").

If I run "270BC" with Hard AI for all players: Do I get to realistic scenarios?

RaiNova

@cernel said in Fast Battle Calculator:

Unfortunately, the "270BC Wars" artillery has the issue that it gets taken as casualty or removed too soon, because the autoselector doesn't see it (so an offence/defence 0/0 unit with some powerful AA ability is just seen as powerless). Reliable results can only be obtained using "Order of Losses".

This also means that the AI removes its artillery units too early. How would you like to express in the xml file where in the order of losses the respective artillery types belong?

RaiNova

@cernel said in Fast Battle Calculator:

I'm not sure what "docu" you are referring to.

Looks like the main docu is pact_of_steel_2.xml, thanks for pointing that out to me ( @beelee thanks to you, too ).
I've also found something on https://axisandallies.fandom.com/ .

I'd prefer an md file in the docs folder of the triplea github repository. Is there anybody else with that demand?

RaiNova

@cernel said in Fast Battle Calculator:

However, I'm not aware such wrong casing has any actual negative consequences. Has it?

It hasn't. I was just picky, because I am uncertain.

Cernel

@rainova said in Fast Battle Calculator:

If I run "270BC" with Hard AI for all players: Do I get to realistic scenarios?

It has been a long time since I did that, but I'm pretty sure Hard AI is going to play the game very differently from any good player.

Cernel

@rainova said in Fast Battle Calculator:

This also means that the AI removes its artillery units too early. How would you like to express in the xml file where in the order of losses the respective artillery types belong?

I'm not sure what you are asking. Do you mean giving the game-maker a way to determine what the autoselection is going to be, like making a list of units from the first to the last one to autoselect? I don't think that would belong to the game file (as long as the player is not forced to go by the autoselection), as such file is about defining the rules of the game. Moreover, a static listing per game would not cover the case of units changing values during the course of the game (usually because of technology).

Are you thinking about something like
https://forums.triplea-game.org/topic/1580/support-priority-definition
but for the autoselector?

beelee

@RaiNova this may prove easier to navigate. Basically same as POS2 I believe

http://www.starlords3k.com/XOB.html