Extremely specific question about damage calculation (WARNING MATH INSIDE)

[rei-Scarred]

Ok so I'm experimenting with coding a combo theorycrafting application. Don't know if I'll run it all the way, but I already have an aggravating roadblock. So in terms of decimal truncation Blazblue cannot decide how it wants to run things.

 

Example combo I'm using for damage testing:

Bang: 5B 2B 6C jC j2C 5A 5B jC

 

Math for this combo's damage =

(5B) 640 +

(2B) 440 = (620) * (.8) * (1) * (.89)  +

(6C) 519 = (820) * (.8) * (1) * (.89 * .89)  +

(jC)  319 = (600) * (.8) * (1) * (.89 * .89 * .84)  +

(j2C) 317 = (650) * (.8) * (1) * (.89 * .89 * .84 * .92)  +

(5A) 130 = (300) * (.8) * (1) * (.89 * .89 * .84 * .92 * .89)  +

(5B)  214 = (640) * (.8) * (1) * (.89 * .89 * .84 * .92 * .89 * .77)  +

(jC)  178 = (600) * (.8) * (1) * (.89 * .89 * .84 * .92 * .89 * .77 * .89)  =

_____________________________________________________

2757

 

So this is the most accurate order of operations I've found so far

 

The "(int)" for those not code savvy basically just truncates anything off the decimal point if there is one. This probably looks wonky but its the most accurate thing I've found thus far. No truncation whatsoever already gives bogus values by the 2nd hit of the combo. Example (620 * .8 * .89) rounded down = 441 whereas (620*.89) rounded down times .8 = 440. 

 

THE PROBLEM

Using my rounding method the longer this combo goes the more often my result is off by 1 damage. It comes out to 179 on the last jC and by the end of the combo if I type in the whole BNB the total is off by 3. Another method I have tried is truncating the decimal on every step of the P2 multiplication and that gave me 178 correctly on the jC but other numbers were fucked up.

 

Some math major please come in here and tell me why I'm being stupid. Or maybe Blazblue coders need a good slap idk.

[Spark]

Hmm I ran into the same problem.  What I think they are doing is they only look at 3 numbers past the decimal point after multiplying out all the proration and using that to scale the attack then dropping anything past the decimal point.

For example for (jC)  178 = (600) * (.8) * (1) * (.89 * .89 * .84 * .92 * .89 * .77 * .89)

(.89 * .89 * .84 * .92 * .89 * .77 * .89) = 0.298681175683968

0.298681175683968 * 600 (j.C) = 179.2087054103808 = 179 after dropping the decimal.

But if you only use .298 * 600 = 178.8 = 178 after dropping the decimal.

 

I didn't test it with all the numbers but it works out correctly when computing the damage for 5B and 5A in the combo you posted above.

[rei-Scarred]

Thank you very much I'll run this and see where it gets me. Never even thought about specific precision for some reason.

 

edit: 

 

Flawless victory. Exact damage of 5B BNB.

[rei-Scarred]

I lied. Still having issues.

 

The method you listed for the combo I have listed adds 1 point of damage to the 2B:

(.89 * .8) = .712 * 620 = 441

 

The way I ended with the correct answer was to multiply by the combo rate AFTER truncating so:

(.89 * 620) = 551 * .8 = 440

 

This works for every hit in this particular BNB but it seems the longer the combo is the more likely an error is to come up. (Odd as I'd expect errors in rounding to be the most significant when the damage is still high...) One such example I found is

5B 2B 6C jC j623B 5B 623B 2B 5B jC jC j2C 5A 5B jA jB jC jC j2C = 4438 damage

 

My calculator only comes up with 4436 and it is losing one damage on the 1st j2C and the last jC

Maths:

j2C = 650 * (.8 combo rate) * (1 P1) * (.89 * .89 * .84 * .92 * .92 * .89 * .72 * .89 * .89 * .92 * .92)

 = .2419... -> round .241 * 650 = 156.65 -> round 156 * (.8 combo rate) = 124.8 -> round 124

 

This hit should be doing 125 damage.

 

For the record if I take out the 1st rounding operation it does 4439 damage: an overshoot by only 1 however doing this makes the combo in the first post not work for the same reason as before. If I take out the 2nd rounding operation the combo does 4442 damage: an overshoot by 6. If I change the 3rd truncate to an actual half round the combo does 4443: an overshoot by 7.

 

It's so hard to figure out a change that will make this work properly without fucking everything else up... My worst fear is that there is some sort of carry over point of damage on some hits...

 

Also super short combo that doesnt seem to work properly...

 

(jA) 300 +

(jB) 275 = (560) * (.8) * (.8) * (.77)  +

(jC) 251 = (600) * (.8) * (.8) * (.77 * .85) =

__________

826

 

The jC in this is doing 250 Order ->  = .77 * .85 * .8 (P1) = .5236 -> round .523 * 600 = 313.8 -> round 313 * (.8 combo rate) = 250.4 -> round 250

 

The salt is real.

[Spark]

Hmm the 5B > 2B being 440 is pretty strange. At first I thought maybe the 5B P2 was wrong(Maybe it's 88.5 or whatever), but if you use crush trigger to check (5B > CT) the damage comes out to 890 which means the P2 is .89. So that can't be it.

5B > 2B

440 = (620) * (.8) * (1) * (.89)

So it looks like the only way this can be true is if P2 is applied to the move damage first then it's truncated then applying the combo rate and then truncating it again. Though with this example it's unclear when the P1 is applied.

620 * .89 = 551.8 = 551

551 * .8 = 440.8 = 440

This seems to work out correctly for 5B > 2C, 5B > 5A, 5B > 5B, and 5B > 5C.

So on to j.A > j.B > j.C

251 = (600) * (.8) * (.8) * (.77 * .85)

This works out to be 250 if you apply P2 round down and then repeat for P1 and CP, but it looks like if you multiply P2(.77 * .85) with P1(.8) then apply that to the damage 600 * (.77 * .85 * .8) it gives us 314.16 rounded down to 314 * CP(.8) comes out to 251.2 which rounds down to 251.

So it looks like you might not have to round the proration values at all.

Doing floor(floor(DMG * (P1 * (All P2s)) * CP) might be correct? Seems pretty strange, but doing that makes the damage values for 5B > 2B and j.A > j.B > j.C make sense.

I'll look into it some more if you find a situation where the above doesn't work.

[rei-Scarred]

This does work for the jA jB jC but I still have issues in the long combos. I'm pretty sure I had that formula or something similar before because these numbers look familiar.

I'll go ahead and copy paste the output of the full combo from the first test case in my first post since it has the most errors. Using that formula the combo from my 2nd post does 4439 damage instead of 4438 and the ONLY error is on the last hit (listing 42 instead of 41 damage):

 

5B

Total Damage: 640

Hit damage: 640

2B

Total Damage: 1080

Hit damage: 440

6C

Total Damage: 1599

Hit damage: 519

jC

Total Damage: 1918

Hit damage: 319

j2C

Total Damage: 2235

Hit damage: 317

5A

Total Damage: 2365

Hit damage: 130

5B

Total Damage: 2579

Hit damage: 214

jC

Total Damage: 2758

Hit damage: 179                   Does 178 in practice. Total damage from here on out should be 1 less

jC

Total Damage: 2922

Hit damage: 164

j2C

Total Damage: 3086

Hit damage: 164

5A

Total Damage: 3153

Hit damage: 67

5B

Total Damage: 3263

Hit damage: 110

jA

Total Damage: 3308

Hit damage: 45

jB

Total Damage: 3374

Hit damage: 66                             Does 65 damage in practice. Total damage from here on out should be 2 less

jC

Total Damage: 3434

Hit damage: 60

jB

Total Damage: 3485

Hit damage: 51

jC

Total Damage: 3532

Hit damage: 47                       Does 46 damage in practice. Total damage from here on out should be 3 less 

j623B

Total Damage: 3625

Hit damage: 93

 

This combo does 3622 damage. Off by 3.

 

If theres any metadata you want me to throw in to make it easier for you to decipher let me know. I'm thoroughly confused.

[KayEff]

it's possible that the game only recognizes a certain number of bits.