Battle Calc Question
-
@ssoloff right on I come up with 24 ones or twos. Which ones should I not be counting ? Also I count 12 sixes in his example instead of 11.
When I do it the opposite way it all works fine.
-
I come up with 24 ones or twos. Which ones should I not be counting ?
@beelee The bold entries in the table below are the ones that should be counted:
:--: :--: :--: :--: :--: :--: (1,1) (1,2) (1,3) (1,4) (1,5) (1,6) (2,1) (2,2) (2,3) (2,4) (2,5) (2,6) (3,1) (3,2) (3,3) (3,4) (3,5) (3,6) (4,1) (4,2) (4,3) (4,4) (4,5) (4,6) (5,1) (5,2) (5,3) (5,4) (5,5) (5,6) (6,1) (6,2) (6,3) (6,4) (6,5) (6,6) Remember, you're counting pairs of dice, not the individual dice themselves.
-
@beelee simple finite = (1/6 +1/6) x 2dice = 66% without going into vast explanation.
-
@ssoloff Cool ! Pairs of dice was where I was screwing up. Thanks for the explanation : )
-
@beelee naw its more of the fact the extra hit isn't being counted in your ?
Triplea is looking at hits that could matter. -
@beelee it also isn't taking inot account subs have first strike ?
-
@beelee ah missed the one round of combat part
-
@prastle heh heh : ) I missed a lot more than that
How you doing brother ?
-
@beelee all good
-
@redrum I actually thought about how to implement it and it shouldn't really be that difficult at all.
Recursion should keep everything pretty simple.
If we can calculate the exact theoretical odds for a single round, we can easily calculate them for n+1 rounds by adding the probabilities of all possible outcomes together multiplied with the probability with each individual outcome.
But I may be wrong about this. Thoughts @ssoloff ? -
@roiex Yeah, if you were to do it then recursion would be the way to go. You are correct that if you can do it for 1 round then its essentially the same calculation for each round. The things that would need proven out are:
- Can we actually come up with a formula that does 1 round in complex/large battles (think 100 units vs 100 units with lots of different types of units with support attachments and AA attacks)?
- Given that you may have to calculate for say 7-8 rounds of battle for these large battles, would it finish in a reason amount of time given how fast the tree expands?
- Would this actually replace the existing battle calc and if not then how painful would it be to maintain it alongside the existing one?
-
@redrum I surely suggest to keep both the Battlecalculator and the Battlesimulator, also considering that this is a volunteer based project, in which anybody can walk away anytime.
-
@Cernel What benefit would you see in keeping "both" variants?
-
@cernel Side feature request, a think I sometimes thought is having a button on the simulator that allows you to show everyone the results and the units in the simulation. Like when you messed up something and would want to rerun the battle and edit it, of course at run count 1.
-
- There may be things you overlook, like AA shots with special properties against infrastructure units or other things, and at least having a simulator would be more reliable if there is not always a developer around ready to cover all unforseen cases the mapmakers may get creative with.
- Maybe a developer would add a feature, but would not be able to rework the battlecalculator; much easier adding features with a simulator; now you are requesting any developers that want to improve or change battle related things to be able to refactor the battlecalculator too; that is a huge additional requirement.
- Already the simulator doesn't cover all cases, like you cannot add marine units and decide to take them in some numbers before or after; covering everything would be even more difficult with a calculator.
- Maybe something in the future bugs off and there are no developers around to correct the problems readily; a simulator is much more reliable than a calculator, as it is not really another thing but what already happens in battle.
-
@Cernel Valid concerns, however I'm convinced that if we code it the right way (so it essentially uses the same code as normal battles) the performance improvements will be huge at no cost at all.
Simply because the code currently simulates battles by copying complete savegames, running the battles there, storing the results and then undoing all the changes.
I'm sure this will reduce the overhead of TripleA drastically -
@roiex I still suggest 1 year time of keeping both before deciding if throwing the simulator overboard.
-
@Cernel There's no reason to keep 2 systems doing the same thing around for such a long time. Either the potential new system works as expected and we keep it and dump the current one, or it doesn't work as expected because stuff isn't working as expected and we dump it instead.
Simple as that.
Nobody wants to introduce a half-broken system just because it's lightweight -
Btw it's easy to forget we can in theory revert all changes that were ever done to the triplea codebase thanks to git.
We can even lookup what the first code being written 16 years ago was exactly -
@roiex shush you
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