## [interface/engine] Advanced damage inflicted/taken hit count statistics

**Moderators:** Forum Moderators, Developers

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

But there's no multiplication involved.Mawmoocn wrote: ↑May 9th, 2019, 8:44 pmMy basis exponential growth is multiplication by itself, grows numbers quick.Tad_Carlucci wrote: ↑May 9th, 2019, 12:11 pmDepending upon the actually implementation, the only thing I could see growing (but linearly, not exponentially) would be an accumulated error.

It won’t be a problem, probably ..........

The code adds up the number of hits and misses for each CTH value. For example, if a side=1 Mage and a side=1 Adept attack and hit four times between them, the statistics for cth=70 will be hits=4 misses=1. In a typical mainline scenario, the only CTH values seen are 30,40,50,60,70,80, so this step results in six pairs of numbers. Then the code simulates N combats, one for each CTH value. The Nth combat has a unit with as many attacks as there were strikes at the respective CTH value; in the Mage/Adept example, the combat representing the cth=70 strikes will involve a unit with 2+3=5 strikes. The combats result in an HP histogram like the ones in the damage calculations dialog. The code sums the first few numbers in that histogram and prints that.

So, the costly part here is basically simulating a combat that has as many strikes as there were strikes in the scenario.

(That was actually my second choice. My first choice was https://en.wikipedia.org/wiki/Poisson_b ... noff_bound but the error there was large, at least in my small test cases.)

I'll post the code as a PR later, when I've cleaned it up. Watch the github issue. (By the way, you made me find a bug, so thanks)

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Technically there are some features that use multiplication.

Number of units, math calculations and things involving division and percentages.

Number of glitches ironically uses "multiplication" .

You could get 90 in mainline units like heavy infantry .

I think this feature would make the entire game slow, assuming it calculates every combat that happens. You probably need a seperate toggle to turn it off.

Combat simulation is present on latest version I think?

I don’t find this necessary for knowing the outcome... well I probably got used playing without one so ... who knows .

Sorry, didn’t expect that to happen any time soon ...

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

I'm not talking about "things" in general. I'm talking about the statistics dialog specifically. The new statistics (#4070) just multiply the number of strikes by the CTH, and add that up for all CTH values. I really don't see anything exponential in this.

It doesn't go through the history of combats, if that's what you mean. It simply runs six combats where the combatants have a large number of strikes. If you had 100 strikes at 60% and 50 strikes at 70% it will simulate a single unit being attacked by a 1x100 60% attack and then by a 1x50 70% attack.

Empirically, it does not make the game slow.

**Spoiler:**

"Combat simulation" is just the code that computes the histogram shown in the Damage Calculation dialog. It's not new.

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

My basis for this is when I played Legend of Wesmere, I had to fight against 50-100 units.... assuming they have minimum of 2 hit strike, multiplied by number of enemy units and turns used to fight them, you could easily record 200-400+ hit count but that depends on scenarios like Elves' Last Stand... by the way, I was stuck on that campaign since I was trying to avoid mass death of units , which I probably need a bit more mastery to make it work.

Another basis is UMC scenarios that .... well unless you deliberately triggered fighting those units... you won’t need to fight them... I did fight against a lot of units .... if you fought 200+ enemy units (not counting your own units), it could easily yield 1000+ hit count.

Retaliation or counterattack will certainly add more hit count, assuming they don’t die.

Well I probably shouldn’t have used exponential as a word. Sorry I made a mistake there.

By every combat, I assume it activates it’s calculation for every unit that will fight, this would introduce some resources to be used by memory and performance. Assuming you’ll fight against more than 50+ units, well there might be memory leaks or some sort of similar problems.

Well it’s mixed, I’m thinking the resources needed to calculate every CTH, would bog slow computers.

Not sure about this.

I think this could suffer from time difference used to calculate results, it’s because of probability for different times won’t be the same.

Basically it probably doesn’t affect anything.

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

No worries. As I said, I just tested the code with 25000 hits and it was fine. Moreover, the code only runs when the stats dialog is opened, so it's not performance critical.Mawmoocn wrote: ↑May 10th, 2019, 5:23 pmAnother basis is UMC scenarios that .... well unless you deliberately triggered fighting those units... you won’t need to fight them... I did fight against a lot of units .... if you fought 200+ enemy units (not counting your own units), it could easily yield 1000+ hit count.

Retaliation or counterattack will certainly add more hit count, assuming they don’t die.

Well I probably shouldn’t have used exponential as a word. Sorry I made a mistake there.

The CTH values are stored as integers, so there are at most 101 of them, so the total amount of memory used by the hits/misses counters is O(1). The only non-O(1) part, I think, is theMawmoocn wrote: ↑May 10th, 2019, 5:23 pmBy every combat, I assume it activates it’s calculation for every unit that will fight, this would introduce some resources to be used by memory and performance. Assuming you’ll fight against more than 50+ units, well there might be memory leaks or some sort of similar problems.

`hp_dist`

vector in the last iteration of the loop in the function `tally`

. The vector will have as many elements as there were strikes in the campaign, each element is a double (8 bytes). In HttT I had 25000 hitpoints of damage over the entire campaign, if somebody does 25000 strikes in a campaign the vector will consume about a quarter of a MB of memory, but if somebody has 25M strikes in a campaign, the vector would require about 200MB memory. On the other hand, 25M strikes is equivalent to playing HttT 10000 times back to back as a single campaign...What are you talking about? There's no time element to any of this.

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

I don’t think.... well UMC can do it definitely...

Well if you could play 10000 times... amazing in another sense .

Lets see... in probability, timing is only important especially if there are factors that enables us to control functionality or it could delay/accelerate something that it affects directly by having a result.

I assume that the statistic to calculate this would be different every time it’s opened, this "could" lead to problems... relating to ...society (human behavior).

I didn’t see a problem yet... so I wasn’t sure.

Hopefully no problems in the future.

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

The tallying of hits and misses is done as the scenario goes along. The summation/multiplication of six pairs of numbers and simulation of combats happens every time the stats dialog is opened, but it takes no time at all (on my machine, anyway. if you compile wesnoth yourself, feel free to build and test the PR).

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Greetings,

I’m not well versed to apply PR changes.

I’ll look for any potential bugs and keep track on your PR.

I think there could be an accessibility option to turn text colors off.

https://developer.mozilla.org/en-US/doc ... r_contrast

I think I’ll make comments here when necessary.

Thanks for trying the possibility of this feature!

I’m not well versed to apply PR changes.

I’ll look for any potential bugs and keep track on your PR.

I think there could be an accessibility option to turn text colors off.

SourceWhen choosing a color scheme for your website, make sure that the text (foreground) color contrasts well with the background color. Your design might look cool, but it is no good if people with visual impairments like color blindness can't read your content.

https://developer.mozilla.org/en-US/doc ... r_contrast

I think I’ll make comments here when necessary.

Thanks for trying the possibility of this feature!

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Which foreground color do you think is problematic over the dark background color of that dialog? You can see a sample of the colors in download/file.php?id=83893. Note that in that screenshot the text is not in a dialog but in a tooltip so the background color is different.

Also, not to be dismissive, but I think accessibility of the stats dialog is lower priority than accessibility of the mainmap (the part of the screen where all units are shown during play). For example, can colorblind users easily tell which unit belongs to which side, even with unit ellipses enabled?

Also, not to be dismissive, but I think accessibility of the stats dialog is lower priority than accessibility of the mainmap (the part of the screen where all units are shown during play). For example, can colorblind users easily tell which unit belongs to which side, even with unit ellipses enabled?

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

I'd like to ask for some opinions on how to present the information.

Currently, it looks like this. That dialog shows the statistics after a single 9x4 attack that hit 3/4. In "3/2.8 65.2%", the "2.8" is the expected number of hits and the "3" is the actual number of hits. Because 3 > 2.8, the percentage shown is the

This is perhaps not the best way to present the information. How could it be improved?

Currently, it looks like this. That dialog shows the statistics after a single 9x4 attack that hit 3/4. In "3/2.8 65.2%", the "2.8" is the expected number of hits and the "3" is the actual number of hits. Because 3 > 2.8, the percentage shown is the

*a priori*probability of getting 3 hits or more. If the actual number had been smaller than the expected (for example, 2/2.8 ), the percentage shown would have been the*a priori*probability of getting 2 hits or fewer. In other words, if you've been lucky the percentage is "How probable was it that I'd be so lucky" and if you've been unlucky the percentage is "How probable was it that I'd be so unlucky".This is perhaps not the best way to present the information. How could it be improved?

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Sorry for double post, but how about this?

It now shows

edit: Changed the screenshot only, fixed issues with intercolumn padding.

It now shows

**both**the*a priori*probability of actual<expected and the*a priori*probability of actual>expected. They'll generally add up to 100.0% but when actual=expected they won't.edit: Changed the screenshot only, fixed issues with intercolumn padding.

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Greetings,

I got tangled up trying to finish a scenario, I procrastinated for a bit...

I apologise for not responding much earlier than intended.

(-70%, -80%) probably has the same issue?

(+0%, +10%) contrast/hue is quite high? Make it slightly darker?

(+60%, +70%, +80%) too "dark"?

Other percentages, have no problems? Not an expert in this field.

Most percentages mentioned, are slightly problematic when I don’t zoom.

(-50%, -60%) make it lighter? It’s nearly similar to (-70%) but can be considered different.

It would look different inside a game and an image preview.

After contemplating what a priori could be, I assume, I probably made a blunder on telling a hypothetical formula?

I don’t know how to calculate "unlucky" statistics....

Damage statistics currently "favours luck". If you have a lower chance to hit and you hit successfully, it will create high percentages, besides other factors.

Math estimations, uses 5 or more, as basis for additive estimations. As estimation is partly influenced human behaviour, we could infer that we probably have slight preferences to higher results.

Based on these facts, we should probably favour small higher percentage to show "luck" percentage.

I didn’t thought this far.........., I forgot to mention this formula: total number of strikes divided by hit chance percent (NT ÷ CTH% = Q), number of successful hits divided by past quotient (NS ÷ Q = R%).

((70 ÷ 80% = 56), 51 ÷ 56 = 0.91071428571429) = 91%.

Though it also has a set of problem....

For individual tally, assuming a silver mage hits 4 out 4 strikes, and use the aforementioned formula, we could face higher percentages than normal, once it exceeds the expected value.

As an example

(4 ÷ 70% = 2.8 ).

Assuming for all successful hit values, this formula would "glitch" when the expected value is lower than the current successful hit...

(1 ÷ 2.8 = 0.35714285714286) = 36%

(2 ÷ 2.8 = 0.71428571428571) = 70% / 71% / 71.4%

(3 ÷ 2.8 = 1.07142857142857) = 107% / 100% round off estimate

(4 ÷ 2.8 = 1.42857142857143) = 143% / 100% round off estimate

It could probably be solved by changing positions... though it will certainly cause new issues....

(2.8 ÷ 3 = 0.93333333333333) = 93%

(2.8 ÷ 4 = 0.7) = 70%

If the result reaches 100% (4/4), calculations will fail horribly...

Probably, we should use factorization for solving this issue...

(1 = 25%)

(2 = 50%)

(3 = 75%)

(4 = 100%)

Though it faces a problem of identifying units to factor, and it disregards chance to hit calculations....

Hooray for unknown complexity ....... ......

If we use the previous formula and add estimation, these are an example of their slight percentage fluctuations.

1. Without estimation:

([29 ÷ 70% = 20.3], 18 ÷ 20.3 = 0.88669950738916) = 88%

2. With estimation only for the last calculated quotient:

([29 ÷ 70% = 20.3], 18 ÷ 20.3 = 0.88669950738916) = 89%

3. With estimation for all quotients:

([29 ÷ 70% = 20], 18 ÷ 20 = 0.9) = 90%

If estimation is necessary, I prefer the second option, as estimation only happens, at the end of calculations.

Depending on it’s intention of purpose, any option has merit.

To calculate the total average percent, we need to calculate hit chances individually, and combine the result percentage, to create an average.

This a partially complete hypothetical example of how overall hit count, could be tallied.

1. NS = Successful number of hits

2. NT = Total number of hits

3. XR = Expected result based from, total number of hits(NT) and chance to hit(CTH)

4. Decimal = Result from ((NT ÷ CTH% = Q) NS ÷ Q = R%), used for estimation

5. RED% = The result of decimal estimation, if round off is applied

6. ST% = The estimated difference between total number of hits(NT) and successful number of hits(NS)

Inflicted (number of strikes)

(CTH Stats) (0.0000000Decimal) RED% ST% NS = (XR / NT)

(00% Stats) (0.00000000000000) 000% 00% 00 = (00 / 00)

(80% Stats) (0.91071428571429) 091% 72% 51 = (56 / 70)

(70% Stats) (0.88669950738916) 089% 69% 18 = (20.3 / 29)

(60% Stats) (1.11111111111111) 101% 67% 10 = (9 / 15)

(50% Stats) (1.22033898305085) 122% 61% 36 = (29.5 / 59)

(40% Stats) (1.26027397260274) 126% 51% 46 = (35.6 / 89)

(30% Stats) (0.88652482269504) 089% 26% 25 = (28.2 / 94)

(All Stats) (6.27566268256319) 618%(3%/18%) / 628%(4%/5%/28%) 346%(57%) 186 = (178.6 / 356)

3% is based on (618 ÷ 600 = 1.03), and 18% is based on (618 - 600 = 18).

4% is based on (6.27566268256319 ÷ 6 = 1.0459437804272) without estimate round off, 5% is based on estimated after result with round off and 28% is based on (628 - 600 = 28).

600 or 600%, is based on how many things are needed to recalculate as average.

The final result, probably looks similar to this?

Overall (hit count)

186 = 178.6 (3%/18%) / (4%/5%/28%)

Well this assumes that you’re lucky. I don’t know how lower percentages would probably look.

Rounding numbers might introduce slight difference on calculations, which could be important for exact accuracy, though it will depend on how it works.

One of the reasons why I’m against rounding numbers is because, in multiplication, decimals no matter how small, creates a large fluctuations on its result. As long as it’s a dynamic percentage, it would be alright?

Another thing I’m assuming...

It depends on unit behaviour? Well not sure about this part, as unit behaviour, probably depends on odd and even number comparison?

As an example, a unit that can only do a maximum of 2 hits, would be hard to compare against a unit that can do 5 or more hits. Even if we give them the same chance to hit, their average will differ, only when you compare them

Which makes makes it problematic, depending on how you interpret this with bias.

Current UI, combines these statistics with chance to hit, to make a variable statistic that probably ignores(???) individual differences.

It probably wouldn’t work so well on maps that forces you to fight in very specific terrains, if this wasn’t taken into account. I presume that it won’t merely rely on luck, if you make huge blunders or has been lucky to hit a unit with low % chance to hit.

I feel that the statistics on your other screenshot, seems weird?

80 / 83.3 doesn’t make sense, I could assume that it’s 95% hit rate when I simplify it without taking into account what hits occurred. It seems too high and near perfect .

We should probably keep the percentages shown, but not together?

I assume putting those two nearby, would confuse you on which percentage should you believe.

I think "actual probability" and "priori probability of expected" percentages, should be respectively underneath Inflicted(hits) or Taken(hits). Though it probably wouldn’t fit smaller screens.

Damage is influenced by other game features (abilities, hit points, leadership, etc...), and it causes variations to damage.

Without adjustment, these calculations can’t be simplified without some modifications, that calculates units damage individually.

Simplification of the aforementioned process, helps us manage to calculate different damages that happens for every unit involved.

Hit count however, does this differently. Without intervention, hit count won’t be influenced by other factors, except if we count hits that aren’t made.

Hypothetically speaking... counting hits would become different once, there’re future features introduced, that alters how hits are counted.

For visual UI, instead of 80 / 83.3, it could be, 80 = 83.3, [80 = 83.3] [28.0%] [72.0%], [80 - 83.3 (28.0%)] [72.0%], [80 | 83.3 (28.0%)].

I’m assuming these are inside an invisible/visible box for symmetrical alignment.

As an example

[0080][/][0083.30][028.0%][072.0%]

[0000][/][0000.00][000.0%][000.0%]

Brackets represent box width. Box width could’ve percentage based width or fixed similar widths. If you use padding or spacing, they could use similar percentage based widths.

Separators could use "=", "|", "-", or similar to it’s functions.

As an improvement (???), decimal percentages, could have a toggle function if it’s deemed necessary. We can hide decimal percentages for hit count statistics (90.912345% to 90%).

"This Turn" and Overall hits probably should’ve different functionalities?

"This Turn" could contain priori, and show previous round damage made/taken retaliation.

Overall hits could contain "final" information related things.

Based on when I look at grayscale images, it depends mostly on the brightness or hue of the color.

If you want to support color blind features to improve the game, I think ellipses should have different shapes for every side (side 1, side 2, side 3, etc...), and won’t be dependent on friendly side or enemy side.

Friendly side or enemy side could have other indicators to show their "loyalty", with darker or lighter hues for their current ellipses, depending on what the user wants (toggle options).

I probably haven’t replied things mainly related to priori. I have some questions to it, I avoided replying until it’s clarified. We could probably be talking about the same thing without knowing .

Feel free to ask about questions and clarifications!

I got tangled up trying to finish a scenario, I procrastinated for a bit...

I apologise for not responding much earlier than intended.

The colors for these percentages (-100%, -90%), causes some eye strain.josteph wrote: ↑May 17th, 2019, 5:10 pmWhich foreground color do you think is problematic over the dark background color of that dialog? You can see a sample of the colors in download/file.php?id=83893. Note that in that screenshot the text is not in a dialog but in a tooltip so the background color is different.

(-70%, -80%) probably has the same issue?

(+0%, +10%) contrast/hue is quite high? Make it slightly darker?

(+60%, +70%, +80%) too "dark"?

Other percentages, have no problems? Not an expert in this field.

Most percentages mentioned, are slightly problematic when I don’t zoom.

(-50%, -60%) make it lighter? It’s nearly similar to (-70%) but can be considered different.

It would look different inside a game and an image preview.

Disclaimer: I’m content with your first linked screenshot. Well the following comments for "luck", probably adds more consequences, that I could’ve missed.

After contemplating what a priori could be, I assume, I probably made a blunder on telling a hypothetical formula?

I don’t know how to calculate "unlucky" statistics....

Damage statistics currently "favours luck". If you have a lower chance to hit and you hit successfully, it will create high percentages, besides other factors.

Math estimations, uses 5 or more, as basis for additive estimations. As estimation is partly influenced human behaviour, we could infer that we probably have slight preferences to higher results.

Based on these facts, we should probably favour small higher percentage to show "luck" percentage.

I didn’t thought this far.........., I forgot to mention this formula: total number of strikes divided by hit chance percent (NT ÷ CTH% = Q), number of successful hits divided by past quotient (NS ÷ Q = R%).

((70 ÷ 80% = 56), 51 ÷ 56 = 0.91071428571429) = 91%.

Though it also has a set of problem....

For individual tally, assuming a silver mage hits 4 out 4 strikes, and use the aforementioned formula, we could face higher percentages than normal, once it exceeds the expected value.

As an example

(4 ÷ 70% = 2.8 ).

Assuming for all successful hit values, this formula would "glitch" when the expected value is lower than the current successful hit...

(1 ÷ 2.8 = 0.35714285714286) = 36%

(2 ÷ 2.8 = 0.71428571428571) = 70% / 71% / 71.4%

(3 ÷ 2.8 = 1.07142857142857) = 107% / 100% round off estimate

(4 ÷ 2.8 = 1.42857142857143) = 143% / 100% round off estimate

It could probably be solved by changing positions... though it will certainly cause new issues....

(2.8 ÷ 3 = 0.93333333333333) = 93%

(2.8 ÷ 4 = 0.7) = 70%

If the result reaches 100% (4/4), calculations will fail horribly...

Probably, we should use factorization for solving this issue...

(1 = 25%)

(2 = 50%)

(3 = 75%)

(4 = 100%)

Though it faces a problem of identifying units to factor, and it disregards chance to hit calculations....

Hooray for unknown complexity ....... ......

If we use the previous formula and add estimation, these are an example of their slight percentage fluctuations.

1. Without estimation:

([29 ÷ 70% = 20.3], 18 ÷ 20.3 = 0.88669950738916) = 88%

2. With estimation only for the last calculated quotient:

([29 ÷ 70% = 20.3], 18 ÷ 20.3 = 0.88669950738916) = 89%

3. With estimation for all quotients:

([29 ÷ 70% = 20], 18 ÷ 20 = 0.9) = 90%

If estimation is necessary, I prefer the second option, as estimation only happens, at the end of calculations.

Depending on it’s intention of purpose, any option has merit.

To calculate the total average percent, we need to calculate hit chances individually, and combine the result percentage, to create an average.

This a partially complete hypothetical example of how overall hit count, could be tallied.

1. NS = Successful number of hits

2. NT = Total number of hits

3. XR = Expected result based from, total number of hits(NT) and chance to hit(CTH)

4. Decimal = Result from ((NT ÷ CTH% = Q) NS ÷ Q = R%), used for estimation

5. RED% = The result of decimal estimation, if round off is applied

6. ST% = The estimated difference between total number of hits(NT) and successful number of hits(NS)

Inflicted (number of strikes)

(CTH Stats) (0.0000000Decimal) RED% ST% NS = (XR / NT)

(00% Stats) (0.00000000000000) 000% 00% 00 = (00 / 00)

(80% Stats) (0.91071428571429) 091% 72% 51 = (56 / 70)

(70% Stats) (0.88669950738916) 089% 69% 18 = (20.3 / 29)

(60% Stats) (1.11111111111111) 101% 67% 10 = (9 / 15)

(50% Stats) (1.22033898305085) 122% 61% 36 = (29.5 / 59)

(40% Stats) (1.26027397260274) 126% 51% 46 = (35.6 / 89)

(30% Stats) (0.88652482269504) 089% 26% 25 = (28.2 / 94)

(All Stats) (6.27566268256319) 618%(3%/18%) / 628%(4%/5%/28%) 346%(57%) 186 = (178.6 / 356)

3% is based on (618 ÷ 600 = 1.03), and 18% is based on (618 - 600 = 18).

4% is based on (6.27566268256319 ÷ 6 = 1.0459437804272) without estimate round off, 5% is based on estimated after result with round off and 28% is based on (628 - 600 = 28).

600 or 600%, is based on how many things are needed to recalculate as average.

The final result, probably looks similar to this?

Overall (hit count)

186 = 178.6 (3%/18%) / (4%/5%/28%)

Well this assumes that you’re lucky. I don’t know how lower percentages would probably look.

Rounding numbers might introduce slight difference on calculations, which could be important for exact accuracy, though it will depend on how it works.

One of the reasons why I’m against rounding numbers is because, in multiplication, decimals no matter how small, creates a large fluctuations on its result. As long as it’s a dynamic percentage, it would be alright?

Another thing I’m assuming...

It depends on unit behaviour? Well not sure about this part, as unit behaviour, probably depends on odd and even number comparison?

As an example, a unit that can only do a maximum of 2 hits, would be hard to compare against a unit that can do 5 or more hits. Even if we give them the same chance to hit, their average will differ, only when you compare them

*separately*.Which makes makes it problematic, depending on how you interpret this with bias.

Current UI, combines these statistics with chance to hit, to make a variable statistic that probably ignores(???) individual differences.

It probably wouldn’t work so well on maps that forces you to fight in very specific terrains, if this wasn’t taken into account. I presume that it won’t merely rely on luck, if you make huge blunders or has been lucky to hit a unit with low % chance to hit.

It depends on how a priori is calculated.

I feel that the statistics on your other screenshot, seems weird?

80 / 83.3 doesn’t make sense, I could assume that it’s 95% hit rate when I simplify it without taking into account what hits occurred. It seems too high and near perfect .

We should probably keep the percentages shown, but not together?

I assume putting those two nearby, would confuse you on which percentage should you believe.

I think "actual probability" and "priori probability of expected" percentages, should be respectively underneath Inflicted(hits) or Taken(hits). Though it probably wouldn’t fit smaller screens.

Damage is influenced by other game features (abilities, hit points, leadership, etc...), and it causes variations to damage.

Without adjustment, these calculations can’t be simplified without some modifications, that calculates units damage individually.

Simplification of the aforementioned process, helps us manage to calculate different damages that happens for every unit involved.

Hit count however, does this differently. Without intervention, hit count won’t be influenced by other factors, except if we count hits that aren’t made.

Hypothetically speaking... counting hits would become different once, there’re future features introduced, that alters how hits are counted.

For visual UI, instead of 80 / 83.3, it could be, 80 = 83.3, [80 = 83.3] [28.0%] [72.0%], [80 - 83.3 (28.0%)] [72.0%], [80 | 83.3 (28.0%)].

I’m assuming these are inside an invisible/visible box for symmetrical alignment.

As an example

[0080][/][0083.30][028.0%][072.0%]

[0000][/][0000.00][000.0%][000.0%]

Brackets represent box width. Box width could’ve percentage based width or fixed similar widths. If you use padding or spacing, they could use similar percentage based widths.

Separators could use "=", "|", "-", or similar to it’s functions.

As an improvement (???), decimal percentages, could have a toggle function if it’s deemed necessary. We can hide decimal percentages for hit count statistics (90.912345% to 90%).

"This Turn" and Overall hits probably should’ve different functionalities?

"This Turn" could contain priori, and show previous round damage made/taken retaliation.

Overall hits could contain "final" information related things.

Don’t take my word for it but I assume they can differentiate other colors.

Based on when I look at grayscale images, it depends mostly on the brightness or hue of the color.

If you want to support color blind features to improve the game, I think ellipses should have different shapes for every side (side 1, side 2, side 3, etc...), and won’t be dependent on friendly side or enemy side.

Friendly side or enemy side could have other indicators to show their "loyalty", with darker or lighter hues for their current ellipses, depending on what the user wants (toggle options).

Please explain how it was calculated and the purpose of 2 percentage of red and green.

I probably haven’t replied things mainly related to priori. I have some questions to it, I avoided replying until it’s clarified. We could probably be talking about the same thing without knowing .

Feel free to ask about questions and clarifications!

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Don't worry.

I just reused a red-to-green scale that's already used by other parts of the interface (help pages, mouseover on the mainmap, etc). If there's some problem with the scale, please raise it on the art forums.Mawmoocn wrote: ↑May 19th, 2019, 1:58 pmThe colors for these percentages (-100%, -90%), causes some eye strain.josteph wrote: ↑May 17th, 2019, 5:10 pmWhich foreground color do you think is problematic over the dark background color of that dialog? You can see a sample of the colors in download/file.php?id=83893. Note that in that screenshot the text is not in a dialog but in a tooltip so the background color is different.

(-70%, -80%) probably has the same issue?

(+0%, +10%) contrast/hue is quite high? Make it slightly darker?

(+60%, +70%, +80%) too "dark"?

Other percentages, have no problems? Not an expert in this field.

Most percentages mentioned, are slightly problematic when I don’t zoom.

(-50%, -60%) make it lighter? It’s nearly similar to (-70%) but can be considered different.

It would look different inside a game and an image preview.

Which one is that? In any case, several changes have been made since then...

The "a priori" number, what's shown to the right of the "/" in the Hits table, is calculated as the sum of the cth value of all

*strikes*, both those that hit and those that missed. (That's the expected value of the number of hits in the sequence of strikes that had played out.) If you make one attack with a Red Mage, then the "a priori" number will be 0.7*4=2.8 regardless of how many strikes hit.

Yeah, there's some bias. For example, when an enemy leader has 80% terrain defense and your first Thunderguard hits, that'll lead to "high" luck in the damage stats. It will skew the hits stats too but to a lesser degree, hopefully. (And in any case it should be negligible when doing stats over a large enough number of battles)

I'm cutting a long part of your answer here that I didn't understand at all. Could you please summarize it? What do you think should be shown for each of the three possible results of a single battle between an Orcish Grunt and a Dark Adept, both on flat terrain?

See above.

Because of regression to the mean, the number to the left is always going to be close to the number to the right. You're going to see 80/83.3 and 86/83.3 and so on.

There's a tooltip explaining what each percentage is. Also, they no longer add up to 100%, see at the end. I'll post a new screenshot to github later today, keep an eye open.

There's no "actual probability". The percentages are the

*a priori*probability of getting

*less than*80 hits and the

*a priori*probability of getting

*more than*80 hits. (See below about bug I fixed)

Thanks. I wouldn't use = here because 80 is not equal to 83.3. I suppose | is an option but I don't think it's very intuitive. Hmm, maybe "80 (-3.3)" or "83.3 ⊨ 80"?

The first table has three columns, the last two tables have five columns each, like this:Mawmoocn wrote: ↑May 19th, 2019, 1:58 pmI’m assuming these are inside an invisible/visible box for symmetrical alignment.

As an example

[0080][/][0083.30][028.0%][072.0%]

[0000][/][0000.00][000.0%][000.0%]

Brackets represent box width. Box width could’ve percentage based width or fixed similar widths. If you use padding or spacing, they could use similar percentage based widths.

Code: Select all

```
1 | 2 | 3
1 | 23 | 45
1 | 23 | 45
```

Right now we always show three significant figures. I don't think this is important enough for a UI button, but I suppose we could reduce it to two significant figures for everyone.

"This turn" means the same in both tables. Feel free to file a feature request on github asking for the "This turn" statistics of the previous turn (what you call "round") to be shown somewhere; when it's done it should be done for both tables together.

Good suggestion.

Suppose you attack with a Red Mage, that's 4 strikes at 70%. The expected number of hits is 2.8 (see above). The

*a priori*probability of getting (exactly) N hits is:

N=0 p=0.008

N=1 p=0.076

N=2 p=0.265

N=3 p=0.41

N=4 p=0.24

So if you hit, say, twice, the first percentage will be 0.008+0.076 and the second percentage will be 0.41+0.24. Well, it

*should*be that number, but in the screenshot it would have shown 0.265+0.41+0.24 due to a bug, which I now fixed, thank you very much! That also means the two percentages will

*never*add up to 100.0%, because the actual result, by definition, has non-zero probability.

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Didn’t expect the questions to be challenging...

I don’t get how to calculate human bias in all of these..... I assume, it would be infinite?

I guess since it’s used widely, either I mention change of background color to be more transparent, or ask arguments against changing it, to get a bigger picture.

There are other considerate options, I picked those based on my assumption on what could be the easiest or the better one.

The goal is to calculate excess amount of individual percentages, combine the sum of these percentage without using estimation, and assume luck based on the sum of all percentages from all visible and encountered chance to hit.

Tried to make a symmetrical data, failed though...

I made a mistake on grouping these numbers...

(60% Stats) (1.11111111111111) 101% 67% 10 = (9 / 15)

Should be like this

Basically this stats would mean

Overall (hit count)

(186 / 178.6 [356]) 57% 628%(6.27566268256319)

If 8 unique values appeared, the average percentage would be 800%. Combined individual percentages, that either exceed or below average, can be the small basis for luck.

Since I’m assuming "luck", these represent future calculations for luck. I don’t get the basis or goal for creating the considerations for luck, is it accuracy, or something to appease a player?

All the calculations below, will assume that they’ll survive and has no chance to die.

I assume the central basis for this is Thunderer.

Examples for 60% hit chance

0 * .4 = .4

1 * .6 = .6

Orcish Grunt 40% hit chance

2 * .4 = .8 * .4 = .32

1 * .4 = .4 * 2 = .8

0 * .6 = .6

Well I don’t get it... but my aim was to adjust probability, to create a center focus of probability, that lowers surrounding probability that isn’t close to the center highest probability. Basically its what Wesnoth damage calculation histogram does.

(5+0)6 ÷ 100% = 16.66666666666667

5 * .4 = 2 * .1666666666666667 = .33

4 * .4 = 1.6 * .1666666666666667 = 0.26666666666667

3 * .4 = 1.2 * .1666666666666667 = 0.2

2 * .4 = .8 * .1666666666666667 = 0.13333333333333

1 * .4 = .4 * .1666666666666667 = 0.05333333333333

0 * .6 = .6 * 2 * .1666666666666667 = .2

If you multiply the following values with the expected number of strikes, it would increase the percentages. The aim was to provide a human readable percentages, to make comprehension of luck, easily understood.

I think it would probably confuse players if we use statistical probability of accuracy.

Both have their own problems, and I tried to reduce its potential complexity... though I can’t figure out a method that’s simple but does all the things mentioned above.

4 * .4 = 1.6 * 2 * .1666666666666667 = 0.53333333333333

3 * .4 = 1.2 * 2 * .1666666666666667 = 0.4

2 * .4 = .8 * 2 * .1666666666666667 = 0.26666666666667

1 * .4 = .4 * 2 * .1666666666666667 = 0.06666666666667

0 * .6 = .6 * 2 * .1666666666666667 = .2

Wesnoth did the values below, it seems quite realistic, though it will fail once you reach higher number of hit strikes.... We probably have another problem of statistical accuracy or human readable adjusted statistic adjustment.

Calculation for 2 hit strike, 40% hit chance

0 = 36%

1 = 48%

2 = 16%

Calculation for 2 hit strike, 80% hit chance

0 = 4%

1 = 32%

2 = 64%

Calculation for 2 hit strike, 90% hit chance

0 = 1%

1 = 18%

2 = 81%

Calculation for 5 hit strike, 80% hit chance

0 = 0%

1 = .6%

2 = 5.1%

3 = 20.5%

4 = 41%

5 = 32.8%

Calculation for 5 hit strike, 40% hit chance

0 = 7.8%

1 = 25.9%

2 = 34.6%

3 = 23%

4 = 7.7%

5 = 1.0%

Wesnoth tries to find the center probability of occurrence, assuming they live.

I think it would raise complexity, and would create more potential for glitches, because order of calculations matter, we would need to decide if calculation will adjust, if they have a chance of death.

More power to glitches?

We could use negative and positive percentage, though I don’t get how negative percentage would work, but it depends if we assume that it can confuse a player on interpreting these percentages.

I can’t make certain promises but I’ll try to create a github account.

I think I made a mistake at suggesting the use of addition, for using it at priori. Multiplication would work better, if we calibrate it well.

I apologize for making a mistake on suggesting addition, I assumed it would be used for estimation, and considered addition faultless, without thinking that addition creates fixed numbers and wouldn’t be good for changing variables.

I don’t get how to calculate human bias in all of these..... I assume, it would be infinite?

I’ll try to report it, but I need to make a sound argument before doing so.

I guess since it’s used widely, either I mention change of background color to be more transparent, or ask arguments against changing it, to get a bigger picture.

There are other considerate options, I picked those based on my assumption on what could be the easiest or the better one.

This one:

I’m having hard time explaining those, feel free to ask, I’m confused on how to explain it clearly... It made me quite confused as well...

The goal is to calculate excess amount of individual percentages, combine the sum of these percentage without using estimation, and assume luck based on the sum of all percentages from all visible and encountered chance to hit.

Tried to make a symmetrical data, failed though...

I made a mistake on grouping these numbers...

(60% Stats) (1.11111111111111) 101% 67% 10 = (9 / 15)

Should be like this

Code: Select all

`(10 / 9 [15]) 67% 101%(1.11111111111111) (Statistic for 60% hit chance)`

`101%`

is successful hits divided by expected result(priori), this is grouped by variance of hit chances.`67%`

compares successful and total number of hits, this is to show what it would look like without any adjustments to hit chance.Basically this stats would mean

Overall (hit count)

(186 / 178.6 [356]) 57% 628%(6.27566268256319)

`628%`

can be the resulting percentage "luck". We can modify `628%`

to show 28% / +28% / 4%/ 5% (depending on how you want to derive luck considerations...), as it showed 6 different values for CTH.If 8 unique values appeared, the average percentage would be 800%. Combined individual percentages, that either exceed or below average, can be the small basis for luck.

Since I’m assuming "luck", these represent future calculations for luck. I don’t get the basis or goal for creating the considerations for luck, is it accuracy, or something to appease a player?

So we’re trying to list the probability of each hit strike?

All the calculations below, will assume that they’ll survive and has no chance to die.

I assume the central basis for this is Thunderer.

Examples for 60% hit chance

0 * .4 = .4

1 * .6 = .6

Orcish Grunt 40% hit chance

2 * .4 = .8 * .4 = .32

1 * .4 = .4 * 2 = .8

0 * .6 = .6

Well I don’t get it... but my aim was to adjust probability, to create a center focus of probability, that lowers surrounding probability that isn’t close to the center highest probability. Basically its what Wesnoth damage calculation histogram does.

(5+0)6 ÷ 100% = 16.66666666666667

5 * .4 = 2 * .1666666666666667 = .33

4 * .4 = 1.6 * .1666666666666667 = 0.26666666666667

3 * .4 = 1.2 * .1666666666666667 = 0.2

2 * .4 = .8 * .1666666666666667 = 0.13333333333333

1 * .4 = .4 * .1666666666666667 = 0.05333333333333

0 * .6 = .6 * 2 * .1666666666666667 = .2

If you multiply the following values with the expected number of strikes, it would increase the percentages. The aim was to provide a human readable percentages, to make comprehension of luck, easily understood.

I think it would probably confuse players if we use statistical probability of accuracy.

Both have their own problems, and I tried to reduce its potential complexity... though I can’t figure out a method that’s simple but does all the things mentioned above.

4 * .4 = 1.6 * 2 * .1666666666666667 = 0.53333333333333

3 * .4 = 1.2 * 2 * .1666666666666667 = 0.4

2 * .4 = .8 * 2 * .1666666666666667 = 0.26666666666667

1 * .4 = .4 * 2 * .1666666666666667 = 0.06666666666667

0 * .6 = .6 * 2 * .1666666666666667 = .2

Wesnoth did the values below, it seems quite realistic, though it will fail once you reach higher number of hit strikes.... We probably have another problem of statistical accuracy or human readable adjusted statistic adjustment.

Calculation for 2 hit strike, 40% hit chance

0 = 36%

1 = 48%

2 = 16%

Calculation for 2 hit strike, 80% hit chance

0 = 4%

1 = 32%

2 = 64%

Calculation for 2 hit strike, 90% hit chance

0 = 1%

1 = 18%

2 = 81%

Calculation for 5 hit strike, 80% hit chance

0 = 0%

1 = .6%

2 = 5.1%

3 = 20.5%

4 = 41%

5 = 32.8%

Calculation for 5 hit strike, 40% hit chance

0 = 7.8%

1 = 25.9%

2 = 34.6%

3 = 23%

4 = 7.7%

5 = 1.0%

Wesnoth tries to find the center probability of occurrence, assuming they live.

I think it would raise complexity, and would create more potential for glitches, because order of calculations matter, we would need to decide if calculation will adjust, if they have a chance of death.

More power to glitches?

My concern is visual aesthetic, well I think they should have differences on their presented information.

We could use negative and positive percentage, though I don’t get how negative percentage would work, but it depends if we assume that it can confuse a player on interpreting these percentages.

80 (-3.3) it looks nice, though at first I thought it means reducing numbers.

I’ll think about creating a proposal, though I think there should be some consensus and it’s value for implementation.

I can’t make certain promises but I’ll try to create a github account.

Did you create your static values or derived values based on variables picked?

To be honest, I’m not good at interpreting math, without basis or reasoning behind it.

I think I made a mistake at suggesting the use of addition, for using it at priori. Multiplication would work better, if we calibrate it well.

I apologize for making a mistake on suggesting addition, I assumed it would be used for estimation, and considered addition faultless, without thinking that addition creates fixed numbers and wouldn’t be good for changing variables.

### Re: [interface/engine] Advanced damage inflicted/taken hit count statistics

Thanks. Right now it looks like this, with one change, instead of three percentage values there are only two, the middle (white) one was deleted.

What do all these numbers mean? I'm guessing it means that there were 15 strikes at 60% cth, of which 10 hit and 15-10=5 missed, so theMawmoocn wrote: ↑May 23rd, 2019, 2:08 pmI’m having hard time explaining those, feel free to ask, I’m confused on how to explain it clearly... It made me quite confused as well...

The goal is to calculate excess amount of individual percentages, combine the sum of these percentage without using estimation, and assume luck based on the sum of all percentages from all visible and encountered chance to hit.

Tried to make a symmetrical data, failed though...

I made a mistake on grouping these numbers...

(60% Stats) (1.11111111111111) 101% 67% 10 = (9 / 15)

Should be like thisCode: Select all

`(10 / 9 [15]) 67% 101%(1.11111111111111) (Statistic for 60% hit chance)`

`101%`

is successful hits divided by expected result(priori), this is grouped by variance of hit chances.

`67%`

compares successful and total number of hits, this is to show what it would look like without any adjustments to hit chance.

*actual*hit rate was 10/15=67% and the ratio between actual and expected number of hits was 111% (10/9). Is that right? Please try to explain more clearly next time.

How did you get at the number 628%? I guess you added the "111%" values for every cth value, but the sum doesn't have any meaningful interpretation.Mawmoocn wrote: ↑May 23rd, 2019, 2:08 pmBasically this stats would mean

Overall (hit count)

(186 / 178.6 [356]) 57% 628%(6.27566268256319)

`628%`

can be the resulting percentage "luck". We can modify`628%`

to show 28% / +28% / 4%/ 5% (depending on how you want to derive luck considerations...), as it showed 6 different values for CTH.

If 8 unique values appeared, the average percentage would be 800%. Combined individual percentages, that either exceed or below average, can be the small basis for luck.

I'm sorry but I still don't understand what you're trying to say. Please explain yourself

**clearly and concisely**.

Visual aesthetic is one thing. I considered aligning the percentage values in different rows with each other, I might do that after merging.

You don't need consensus to file a feature request. You file the feature request to see if there's consensus.

These values are the probability mass function of the binomial distribution B(4, 0.7).