Strange "90%" rule occurence

[SoulMan]

to KGB:
Something is definitely wrong here and I will explain according to Your 1st answer.

1. There were 79% rule, so only outcomes between 21% and 79% (middle 58%) can be real - ok, that's how exactly we understand this rule.
2. Without this rule chance that LC will die without killing any unit was 78,7%, so chance of killing at least 1 unit was 21,3%.
3. So 21% on the left cuts nothing here, (this 21% is INCLUDED in 78,7%).
4. And 21% on the right should cut all above 79% and not anything between 21% and 79% (especially 78,7%).

3 and 4 explained more clear (just because I see Seraad was explaining this way before):
First 21%: LC dies (this is cutted by rule, cannot happen)
Next 57,7%: LC still dies (so it's allowed outcome)
Next 0,3%: LC kills 1 unit, then dies (it should be allowed as well!)
Next 21%: LC kills 1 or more units (this is cutted by rule, cannot happen)

Allowed (middle 58%) is bold.
So generaly, rule (should have) reduced chance that LC will kill any unit from 21,3% to 0,3/57,7 (about 0,52%)


I think Seraad might be right about some rounding problem (but it would be strange till it's only 1000 simulations before "true" battle, so minimum > 0 is 0.001, hard to imagine that game misses 0.001, but possible it's rounding to just 2 places)


EDIT:
Ok, I have just found the solution! Let's imagine 1000 simulations from the most unlucky to the most lucky for LC, so we will have:
787 LC died, for example 103 where LC killed one unit and 110 where LC killed more units. Some (not all, but the most) of those 103 has been cutted by the rule, and one of those is exactly what happened.

[KGB]

BTW. I think I know the reason for the "bug"
My guess is the system counts all the probabilities from one side to sum up to 21%. In my case:
P0 - my lc kills 32 and wins whole battle
P1 - my lc kills 31 units
P2 - my lc kills 30 units
......
P30 - my lc kills 2 units
P31 - my lc kills 1 unit
P32 - my lc kills 0 units


So the system sums P0 + P1 +...+Pn to the point it reaches 21% and rules out all the probabilities before reaching 21%
The problem in my case is that probabilities from P0 to P27 are extrelmy low and near 0.
So my guess is that the system rounds the probabilities to 0 - this way sum of all possible probabilities is lower then 100%.
So P32= 78,7% bu sum of P0 to P31 was lower then 21% due to the roundings.

SnotlinG, Piranha?Could you confirm?

Seraad

YES! This is EXACTLY how the rule works! It's sums up outcomes starting on the left and right until it reaches X% (21 in your case) and discards those as outliers which they are. That's why there isn't any bug and it's working as intended.

It's easiest to understand the rule if you imagine 8 lc vs 8 lc with no bonus's. The numbers are going to be something like (I'm guessing here):

.01 .1 1 4 8 10 12 15 | 15 12 10 8 4 1 .1 .01 (roughly 50% on each side spread over 8 units).

So when you remove say 10% from each side you remove .01+.1+1+4 which are the cases of 8,7,6,5 units left for 1 side. So the valid outcomes are 1-4 units left for either side (the middle of the battle).

KGB

P.S. It's possible there is a rounding error when adding a large number of outcomes (20+ units) due to only doing 1000 simulations as SoulMan noted however I have lost 89.9% battles before so rounding isn't intentional and I doubt there is any thing that can be done short of doing more simulations (which the game doesn't have the CPU for).

[Seraad]

KGB,
Again - you don't follow my reasoning at all, but answer only to a particular parts. It is hard to discuss this way.
ie:
a) you say A is true
b) I say that IF (A is true) THEN (B is true)
c) you refer only to B - no no no, B is not true! you say, not following my reasonuing from point (b) at all

And you refuse to answer my question from previous post which could help me tell you why you are wrong

Same on my last post - you agree that that is the way it works, but you don't see that this way my case from the first post is a real bug due to roundings (which causes that the sum of all probabilities in a battle is <100%, which IS unintentional bug), and NOT due to statistical error (to which you refer to saying, that making more stimulations would solve the problem.
it would not solve the problem at all.
Adding more simulations would solve only the problem of statistical error only, not the problem of roundings probabilities.

I only hope Piranha or SnotlinG would write anything on this subject...

Seraad

[KGB]

Seraad,

Is this the question you are saying I am not answering?

I----------------------------------A------------------------------------I------B------I--C--I
I--------------------------------------------------------------------------------------------I
I--------X--------I-------------------------Z-----------------------------I--------Y--------I

where (probabilities):
A - 0 defenders die
B - 1 defender dies
C - 2 or more defenders die
X = Y - represents our "90% rule"
A+B+C = 100%
X+Z+Y = 100%

CASE 1 (my case, roughly showed in the "diagram" above)):
A = 78.7%
X = Y = 21%
Z = 58%
B = 16.3% (rough assumption we can agree with?)
C = 5%

This diagram is correct. It's essentially what you say 2 posts ago when you summed up p0+...p32 and figured p0-p31<21%. Otherwise I am still not sure what question you are asking that I have not answered. To me it seems we are in agreement on the rule and that it's working correctly.

The only question seems to revolve around rounding of numbers. I think I recall Piranha rounding numbers to the nearest % (so 78.7 would round up to 79) or 1/10 of a % because of speed/accuracy issues in the early development days (you can probably search for those posts where we discussed it). It may even have been done to get whole percent values to compared to the 90% rule which uses whole percents.

Incidentally the game itself is full of these type of rounding errors. This is why for example any hero with UL 10 can't lose when searching a L1 ruin and facing Skeletons (even 4 of them). The rounding causes the skeletons to have no chance to make a hit.

Adding more simulations would solve only the problem of statistical error only, not the problem of roundings probabilities.

This is in fact a MUCH bigger problem than you realize. 1000 simulations tends to lead to a variance of 2% (or more) quite regularly from the actual value. So you get 50/50 battles being reported as 48/52 or 49/51. Doesn't seem to be important until you realize that battles that are truly 88% can get simulated to 90% causing an automatic loss instead of a chance for the other side (or vice versa, 91% battles get reported as 89%). That 2% variance affects WAY more battles than rounding 1/10s of a percent.

KGB

[Seraad]

ok, we are heading somewhere

so let's continue step by step
1) My scheme is correct

2)

This is what happened in your battle. There was no way your lc could kill the first unit because it's % chance to win was more than the entire middle section of the battle (58%) so your lc couldn't reach any other units.

Does that mean that according to you if A>Z (see scheme), then A is granted by the rule? (in this case A=78.7% Z=58%)

[KGB]

Does that mean that according to you if A>Z (see scheme), then A is granted by the rule? (in this case A=78.7% Z=58%)

Yes. It must by definition.

The easiest way to understand this is to consider a 1 unit vs 1 unit battle. If that battle is 91 | 9 using a 90% rule then the 91% unit always wins. How could it not? So for example a 30/3 Barb always beats a 10/2 lc.

Adding more units to the side with the 91 unit doesn't change anything. Those units just sit behind the 91 unit and of course decrease the 9% unit chance of winning the battle (say 5 91 | 4 with 3 units, 3 5 91 | 1 with 4 units and so on) and increase the chance of winning to the 91 side. So for example a 30/3 Barb (in front) always beats a 10/2 lc even if there are 31 more lc sitting behind that Barb.

Of course if fight ordering changes so that the 91 unit goes to the back behind some weaker units then the lone attacking unit can register kills. So for example a 30/3 Barb (in back) with a 10/2 lc (front) will always beat a 10/2 lc but 50% of the time the lc in front of the Barb will die.

KGB

[Seraad]

Fine

Let's continue

1)My scheme is correct (we both agree)
2) If A>Z then A is granted by the rule (according to you)

so...
3) Let's put some variables in my scheme
3a) Let the X = 26% (so Z = 48%)
3b) Lone barb 3/30 attacks barb 3/30 then li 2/10 then li 2/10
3c) In this fight probabilities in my scheme are as follows:
A = 50.00% (attacking barb dies killing nothing)
B = 9.35% (attacking barb dies killing only defending barb)
C= 40,65% (attacking barbs kills at least 2 units)

so.. since A>Z then according to you the attacking barb has no chance to win as the only possible outcome is A here!!!!
Do you really think it is true? If not - please show me where is the error in reasoning

Seraad

[KGB]

Seraad,

Aren't you missing an outcome here?

Attacker: Barb
Defender: Barb, LI, LI.

So there should be 4 total outcomes: lone Barb wins | 3 defender outcomes (Barb wins, 1st li wins, 2nd li wins). You only listed 3 and one of those (C) needs to be split into 2 outcomes. I need the following info:

X | Y 9.35 50

Where X = chance lone Barb wins the battle and Y is chance the 2nd li wins the battle (ie finishes off the Barb) such that X + Y + 9.35 + 50 = 100%

KGB

[Seraad]

KGB
Not at all
C = at least two defending units are dead That means either the attacking barb is dead killing 2 units, ir he survived.
So yes Probability of C is sum of 2 probabilities, but it does not mean anything according to my scheme. I can give you the exact probabilities of.. say C1 and C2. But it does not change anything!!!!!

So back to my question . Do you thing C in my scheme is defined inproperly? Or anything else is wrong in my previous post?

Seraad

[KGB]

Seraad,

Ah, OK I see you don't care what X + Y is, I can use any 2 numbers there.

Now I realize that in my prior post I made a slight error about auto-wins. It should be if A > (X + Z) then A is granted by the rule (auto win). Forgot to include that in the 91 | 9 example since 91>(80+10). Sorry about that.

So in your example 50 < (48+26) so it's not an auto-win.

KGB