Fast Battle Calculator
-
@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?
-
@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?
-
@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.
-
@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.
-
@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? -
@RaiNova this may prove easier to navigate. Basically same as POS2 I believe
-
@cernel said in Fast Battle Calculator:
@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?Ideally, in my opinion, the auto-selector should present a selection that, for the whole combat, dynamically assures the average TUV swing is going to be as favourable as possible to the side under the assumption that the other side has the same dynamic selection. Even for simple games, this may be tricky when it comes to decide whether or not to take bombers before something else in defence (for example, taking defending bombers before fighters surely improves the defender's winning probabilities but it may or may not improve its TUV swing). Even better, you should have an option to, instead, select as to maximize your winning probabilities (which is often what you want when you are defending a capital).
To keep it simpler, you may go with just maximizing the winning probabilities, as I surmise that would be much easier to code (hoping users won't missclick defending bombers out too often).
Of course, I realize this will most likely never be, at least not with full coverage, especially for something as complex as the AA (targeted) fire.
As far as the AA (targeted) fire of "270BC Wars" goes (which is called "artillery" in that game, but that's just a customized naming which has nothing to do with what "artillery" usually is in other TripleA games), that is actually relatively simple: it works exactly like the "first strike" ability of submarines, but with the added properties of never hitting "wall" units and always "one-shotting" multiple hit-points units (namely, "fort" and "warelephant").
-
To keep it simpler, you may go with just maximizing the winning probabilities
That‘s pretty much how it works today, and I can build the new battle calulator on top of that quite well. It however means that BC270 wars artillery is killed first since it has no fighting power after the first strike.
-
@rainova
Im not well versed in the use of the Battle Calculator, but does it automatically take into account the rounds a battle take as defined in xml ?
eg.
land 3 rounds
sea 2 rounds
air 1 round -
@rainova said in Fast Battle Calculator:
To keep it simpler, you may go with just maximizing the winning probabilities
That‘s pretty much how it works today, and I can build the new battle calulator on top of that quite well. It however means that BC270 wars artillery is killed first since it has no fighting power after the first strike.
It attacks every round.
-
@thedog After a bit of debugging and testing, I believe that the battle calculator ignores the Air/Land/Sea Battle Rounds settings. Both when called from the BattleCalculatorDialog and when used by the AI. I'd consider this a bug. The PR regarding my battle calculator will be quite big. From experience with my first TripleA PR, I'd like to keep it as small as possible. So I'd like not to fix this bug within the current PR.
-
@cernel Is attacks every round
The battle dialog shows the artillery left of the column "1", i.e. it has no hit power.
-
What is an air battle?
Is every battle that starts out with only air units involved an air battle?
Also if there is infrastructure in the battle location?
Is a battle with only air units and aircraft carriers also an air battle?
Is a ballte with only aircraft carriers also an air battle?
Is a battle with only air units and defending aircraft carriers also an air battle? -
@rainova said in Fast Battle Calculator:
@thedog After a bit of debugging and testing, I believe that the battle calculator ignores the Air/Land/Sea Battle Rounds settings. Both when called from the BattleCalculatorDialog and when used by the AI. I'd consider this a bug. The PR regarding my battle calculator will be quite big. From experience with my first TripleA PR, I'd like to keep it as small as possible. So I'd like not to fix this bug within the current PR.
As mentioned I dont use it much, but thanks for the heads up!
Personally I view the above Battle Rounds as very low priority.
-
@rainova said in Fast Battle Calculator:
What is an air battle?
Air Battle is for airUnits and takes place before regular combat. You can set how many rounds you want the airBattle to last in map options and whether the attacker or defender can retreat. You can also set it so the air battle happens before strategic bombing raids
-
@rainova said in Fast Battle Calculator:
@cernel Is attacks every round
The battle dialog shows the artillery left of the column "1", i.e. it has no hit power.
As I've already pointed out, those are offence/defence 0/0 units with special AA (targeted) fire abilities.
-
@thedog Just to maximise information about the game: The battle calculator does take into account the Air/Land/Sea Battle Rounds settings.
-
Normal approximation to the binomial, to speed battle calculator for large battles? Does that suit?
Since I don't know much math or programming I'm just taking a shot.
-
The question of why the original calculator needs to make a game copy was not answered. The answer is kinda complex, but essentially as the game simulates battles, it is actually fighting real battles. If the game data were not copied, the units on the field would be actually modified.
Overall, this is rooted in
GameDatabeing a god object and relatively monolithic design for how game data is handled. There is no reason the UI of a battle calculator should really take that long, it only needs a few rules like unit stats & images. The battle logic instead requires massive parts of theGameDataobject unnecessarily and then in addition to this the data is largely mutable.All this is to say that a TripleA 3.0 rewrite of how the game rules are stored and a rewrite of how
GameDataworks should resolve a number of these issues.@RaiNova 's approach is slightly different as the odds are calculated rather than simulated, which avoids the problem of mutating game data.
-
Hmpf, I'll have to learn how to program, then I can get my paws dirty. Set up a Github account then just jump in, sound like a good idea?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login