Larian Studios Forums Baldur's Gate III Baldur's Gate III - General The Rogue - Maths are WRONG

Heh, I was just debating that rogue class is great, on steam, and then went into reviewing sneak attack damage. I took a screenshot to show facts and then ... hey, wait ..

Screenshot - and Evidence !
[img]https://steamcommunity.com/sharedfiles/filedetails/?id=2370648672[/img]

From my screenshot you can see the following:
The operation: 4(1D6 Piercing) * ((4(level) -1)/2 + 1) = 8

Now plain math w/ PEMDAS (hope you guys from the 80's remember that) :

4 * ((4 - 1)/2 + 1) = 8 ---> that's not 8. You can also just paste this operation in google ... my god, the math are wrong, can't believe it

4-1 = 3
3/2 = 1.5
1.5 + 1 = 2.5 ----> was that number round down anyhow ? If you round it .. it should be UP .. not DOWN or was it that in the code the .5 was dropped ?
4 * 2.5 = 10 ---> the answer with no round number.

No idea what the calculation gibberish is there for, but if your dexterity is 18 and the number rolled on 1D6 is 4 then 8 is the correct damage.

There's no mathematical rule that says how numbers should be rounded off. Rounding numbers is a social convention for expressing approximate numbers.

As far as I can tell under D&D 5E rules, you ALWAYS round down any time you get a fraction. Even if the fraction is 0.9, you round it down.

Yes, rounding numbers are a convention known throughout the history. Precisely, rounding number 5 UP is also a convention.


Please quote that rule here. And if true, then, it means D&D doesn't understand math.


To the point though, the decimal is within the operation and you don't round numbers before the end of the operation, and that IS a mathematic rule, hence why you get 10 in google.

Hi Dwig, no need to understand if it's too hard for you. Just open a browser on google and paste the operation from the screenshot showing the damage:
4 * ((4 - 1)/2 + 1)

See the answer it returns, provide your observation. good luck.

Larian calculates the Sneak Damage wrong.

For 4th level a rogue should get +2d6 sneak damage once a turn.

So let's assume your rogue is lvl 4 and has 18 Dex.

So for the damage, if you are hitting a target with a dagger (1d4 piercing) and are eligible for a sneak attack, the damage should be:

1d4 + 4 (ability modifier bonus) + 1d6 + 1d6

The last two +1d6 are of course the 2d6 sneak attack damage bonus.

There's one more general rule you need to know at the outset. Whenever you divide a number in the game, round down if you end up with a fraction, even if the fraction is one-half or greater.

- Page 7 (Introduction) of PH 5e.

It has absolutely nothing to do with (not) understanding math. Perfectly normal for e.g. a software developer.

@daMichi - Hi

Well, at least the math would be right .. and simpler. Let see how it progress with upcoming patches and version 1.0.

thanks for the inside.

Look, the operation is this: 4 * ((4 - 1)/2 + 1)

Before you think about rounding a number, or throw a D&D card rule on the table, you run the operation as-is. Once you get "the final answer" then you can add whatever gaming rules that pleases you.

And that's how it should be treated by a compiler - at least that's how google treats it.

I don't quite get the formula they are using.

Why 1d6 * ((level - 1)/2 + 1) ?

The amount of Sneak Attack damage would be (Level/2 rounded UP) * d6

And you ADD that to your weapon damage, not multiply the weapon damage roll with it ...
Sorry, I am too stupid to understand the formula.

Can somebody explain?

If the compiler only works with integers, not with float numbers (as you would use them in C), then it just drops everything after the decimal point.

@daMichi,

The rational as why using this formula will have to come from the dev.

But to explain some of it, it goes as follow:

This is sneak attack, and it looks like your dex modifier doesn't count here. So the formula, as disclose by the log goes like this:

weapon damage X * (((level -1)/2) + 1)
- The parenthesis after 2 is assumed to be there before you go to addition/soustraction;
- The block with the parenthesis is to be solved before the multiplier of the weapon damage integer.

I know. And if a compiler stores a number in a variable which classified as integer, then only the numbers before the decimal point get stored.

So my variable DMG is an integer in C.

I calculate something, and the result is 3.14

I store it in the variable DMG.

The next time the program calls on my variable, it will read 3.

Maybe that's what's happening here. So 2.5 becomes 2.
3.643796337899 would become 3.
And 146.953479544 would become 146.

Well with C, if you use the math.h library with "%.2f" format, you will get the decimal you need in your program.

I don't think they'll be a viable reason for justifying 4 * ((4 - 1)/2 + 1) = 8 instead of 4 * ((4 - 1)/2 + 1) = 10.

Assuming your character is 4th level, you should have 2d6 sneak attack damage, added on top of your regular damage 1d6 damage roll. It should look like (1d6+4)+(2d6). Generally the number of sneak attack dice you get is level/2 rounded UP.

So when I look at what they're trying to do.

Roll result 4(1d6)*((4-1)/2+1)=8

I read it like this.
They rolled a 4 on the weapons 1d6. They're then going to use that same result on all the subsequent sneak attack dice
So if we look at the first part, they rolled a 4 on their weapon damage.

The next set is trying to calculate the number of sneak attack dice.
(4-1)=3
3/2=1.5
1.5+1=2.5
They have to have rounded the result from 2.5 to 2, in order for the result to be 8.


Now wait.
If you're level 4, you should have 2 sneak attack dice, right? (The above formula also works for higher levels. 9 results in 5d6)
1(d6)+2(d6), and d6=4, the result should be 12, not 8.

So the mathematical error I'm seeing is...they subtract 1, divide, then add the 1 back.

If this is supposed to roll 1 dice, and then multiply by the total number of dice, then they should be adding only 1.

Roll result 4.
4*((4/2)+1)=12

Even then, that's actually not correct because we should be adding our dex modifier to our regular damage.
So it should be
4*((4/2)+1)+4=16



----EDIT----

New info
So, I just pulled up the game, and had Astarion sneak attack someone.
I saw two entries for damage.
1 Weapon damage. (1d6+DEX MOD)
and
Sneak Attack damage

Since they aren't actually combining all the damage from regular attack & sneak attack, the math checks out.
I rolled a 1 on my weapon damage, +2 for 3 damage.
And my sneak attack rolled a 4, so I did 4 damage.

I understood the numbers quite well (physics phd and all), what I do not understand is WHY they are being used. The 5E calculation for damage is weapon die + stat modifier for most hits (there SHOULD be no stat modifier on off hand hits, but BG3 does not follow this rule).

For a sneak attack there should simply be more dice. A level 4 rogue that hits with a valid sneak attack should roll 2D6 and add that to whatever the rest of their hit was. The equation appears to be a multiplier, but there are no multipliers like that in 5E that I am aware of. The hit was not critical, and even if it were the correct procedure would be to roll all damage dice twice (not apply some strange multiplier).

So the equation simply does not follow any rule for 5E that I am aware of.

As an aside regarding round off conventions... it is not all that uncommon to simply drop the fraction, depending on your goal. For instance, if you want to calculate the appropriate number of sneak attack dice then the equation (level -1)/2 + 1 will actually work, IF you drop fractions (this equation would then start at 1 die at level 1, and add a die on every subsequent odd level, which is exactly how it is supposed to work). In fact my best guess is that this is indeed what that equation means... but it is horribly formatted.

Yeah it really looks like Larian multiplies the weapon damage die with the number of Sneak Attack dice you get as a rogue at a certain level.

That would explain the notion behind that formula.

*Sigh* another thing that supports that Larian doesn't want to use DnD rules.
It's not like the rules for sneak attack damage would be very complicated, but they just didn't want them in the game.
As to why, I really would like to know.

I have no idea. Could it be a lazy coding thing? Mind you I don’t have a clue about coding so I could be totally off base.

Is it simpler to use a set equation throughout all levels instead of having to add a die to damage as rogues level up? And does this mean they will be using this type of equation for other classes and their abilities that scale up?

Maybe it's a bug, not a feature. We simply don't know,

They calculate the number of Sneak attack dice per level, they just need to set that number to roll that number of 6 sided dice.
It's not that complicated, at least in my opinion.

But I am completely with you here spectralhunter, I also don't know a thing about coding apart from 'Hello world', so I am not in a position to really tell.

I don't know if they use it somewhere else.
My PC broke down before Christmas and I wasn't able to build a new one till now (waiting on the graphics card).

But once again I have a PC I want to play BG3 and have a good look at stuff like this.

So, my recollection of sneak attack when I played in December... whenever I connected with a sneak attack there would be two damage numbers floating by. I assumed at the time that one was the weapon damage and the other was the sneak attack damage.

IF that is correct, and IF the equation reported by Starlights is JUST the sneak attack portion, then what we have in this equation is a correct calculation of the number of dice, but an incorrect application of that number as a multiplier.

They appear to be taking the result of a single D6 and multiply it by the number of dice. This will give the same range of results as the correct procedure of just rolling extra dice, but it will be a flat distribution rather than a bell curve (meaning that extreme values, both high and low, are more likely). I suppose this isn't the worst thing in the world, but I don't know why they can't just roll the dice more times, there is no way that this "short cut" saves a meaningful amount CPU relative to just doing it correctly.