Fast Battle Calculator
-
@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?
-
@aardvarkpepper We could sincerely use the help. It's a deceivingly difficult code base though, frustrations be ahead..
-
@lafayette You really know how to motivate people
-
@frigoref Yes, I'm good at it = D
It's probably better for folks to see the grit for themselves, though I feel like there should be some forewarning & full disclosure that getting things done requires tenacity. -
@aardvarkpepper It's nice to read that you'd like to get involved more technically!
The TripleA code base is 21 years old and she's sometimes behaves as obscurely as if she just turned seventeen.
If you want to learn programming, I suggest you start at something simpler and smaller.
If you want to get technical with TripleA, I suggest you help with the bugs. https://forums.triplea-game.org/topic/3138/staying-3digit-with-open-issues is a quite active discussion how to get a hold on them, and @frigoref is doeing a great job organizing the work.
A bug is reported in form of an issue entry in https://github.com/triplea-game/triplea/issues
We were approaching a thousand open issues, and the guys already brought it down to 739. I am looking forward to your contribution!
-
@rainova said in Fast Battle Calculator:
If you want to learn programming, I suggest you start at something simpler and smaller.
If I'm going to build a program similar to TripleA, makes sense to look at TripleA.
@rainova said in Fast Battle Calculator:
If you want to get technical with TripleA, I suggest you help with the bugs.
From a purely programming view, sounds good to me.
@lafayette said in Fast Battle Calculator:
@frigoref Yes, I'm good at it = D
It's probably better for folks to see the grit for themselves, though I feel like there should be some forewarning & full disclosure that getting things done requires tenacity.I had some idea from reading other threads, but I liked that it was brought up there. Way I figure it, anyone expecting to just chip in will see for themselves before too long that there's a lot going on - or at least, so I gather from other threads.
Going to be quite a while before I can get up to speed. I don't think there's much up to date documentation?
e.g. documentation on stuff like variable naming conventions, how the program should be structured in terms of objects and references, how modules are broken out &c.
I'm not concerned about a lack of documentation, I'm sure I'll piece it together. But if there's a file just sitting somewhere, might as well get it, right?
Bringing it back to fast battle calculator, if I understand right, probably Rainova's solution was to use Low Luck or something maybe? And LaFayette said the battle calculator references too much so is slow, and I expect TripleA 3.0 will be structured so the issue won't exist. So for the time being, is this topic addressed? That is, if there are no forthcoming changes to 2.6, and it'll be addressed with the next major (eventual) release?
-
@aardvarkpepper , re: documentation
New developer tutorial:
https://github.com/triplea-game/triplea/tree/master/docs/development/tutorialDocumentation overview:
https://github.com/triplea-game/triplea/tree/master/docsAll things dev:
https://github.com/triplea-game/triplea/tree/master/docs/developmentCode conventions (naming/java):
https://github.com/triplea-game/triplea/tree/master/docs/development/reference/code-conventionsTypical git commands & workflow:
https://github.com/triplea-game/triplea/blob/master/docs/development/how-to/typical-git-workflow.mdSome of the best first changes are updating & fixing up the above documentation. The fresh perspective is really valuable to incorporate.
We now have a 'good first issue' label, though not a lot is yet tagged with it: https://github.com/triplea-game/triplea/issues?q=is%3Aissue+is%3Aopen+label%3A"Good+First+Issue"
The error reports could be a fine place to start. For those we typically try to repro, if we can't then we try to force it in the code by making some modifications to force the error. Then fix, verify & PR it. Those are decent starter issues because there is a stack trace which gives some good direction of where to look & what to fix: https://github.com/triplea-game/triplea/issues?q=is%3Aissue+is%3Aopen+label%3A"Error+Report"
