[Tarigar]

Sat - Split off from Diminishing Returns on Avoidance? Not really. to keep that thread on-topic


Ok I have a question and it applies to this thread since it is all based around avoidance. This is avoidance in relation to the combat table. From my understanding there is 100 specific outcomes based on RNG.

If this is true. How do decimals fall into play? I am going to pretend to be a dk now to make the calculation even more simplistic.

So the stats we have are 28.02 Dodge, 18.52 parry, and 12.54% miss. Now we always look at the decimals when we compare and add up avoidance. But if this really factors in when does it. Does it factor in when we get a full percentage gain, does it always round down, or is the combat table more on a 10000 chance for a different outcome?

So I will include the decimals and round for the different scenarios.

10,000 roll system
01.00 - 12.54 = Miss
12.55 - 40.56 = Dodge
40.57 - 59.10 = Parry
59.11 - 100.00 = Hit

Round Down
01.00 - 12.00 = Miss
13.00 - 40.00 = Dodge
41.00 - 58.00 = Parry
59.00 - 100.00 = Hit

Percentages make a whole
01.00 - 12.00 = Miss
13.00 - 40.00 = Dodge
41.00 - 59.00 = Parry
60.00 - 100.00 = Miss

So the 10000 roll system and the round down look like they would have the same effect. But you just now have 100 x the result of what will happen.

If you compare the round down vs. where each decimal of avoidance can = a whole, then we can effectively push another hit (mitigated or unmitigated) off the table.

So will that little .27% avoidance be beneficial or are we stuck?

I know in most of the other mechanics the game rounds down.

[Molohk]

Where did you hear the combat table was discrete? As far as I know decimals are used (and that's how most RNGs work anyways).

[Tarigar]

Source: Molohk Where did you hear the combat table was discrete? As far as I know decimals are used (and that's how most RNGs work anyways).

But if people consider it a roll from 1-100 then how can you get 1.15 from a roll.

If I do /random in game it will never be xx.xx it will always be a whole integer.

[Molohk]

Do not confuse /random or /roll with computer RNGs. In programming, RNGs are routines that generate a random value between 0 and 1 (usually, not including 1), so you can get 0.1 or you can get 0.66666666666666. Mechanisms like /random usually use a RNG, and then multiply it by 100 and round it up, to give you the final rounded number between 1 and 100. Mechanisms like combat tables allow the decimals to take place, to make a more precise system.

/sorry about hijacking thread.

[Tarigar]

Source: Molohk /sorry about hijacking thread.

The reason I asked was because I was confused... Because it does make a difference and that is why I asked the question. 1 hit is 1 hit that we just avoided. Also knowing that if that extra 0.27%(choose your stat) doesn't push me past that next integer in avoidance what am I really gaining?

Edit: and I quoted the /sorry to say don't worry .

[tuffmuffin]

Source: Tarigar Ok I have a question and it applies to this thread since it is all based around avoidance. This is avoidance in relation to the combat table. From my understanding there is 100 specific outcomes based on RNG. If this is true. How do decimals fall into play? I am going to pretend to be a dk now to make the calculation even more simplistic. So the stats we have are 28.02 Dodge, 18.52 parry, and 12.54% miss. Now we always look at the decimals when we compare and add up avoidance. But if this really factors in when does it. Does it factor in when we get a full percentage gain, does it always round down, or is the combat table more on a 10000 chance for a different outcome?

/roll 1-10000 = combat table, I'll use the numbers you did as an example
12.54% Miss, 28.02% Dodge, 18.52% Parry
1-1254 = Miss
1255-4056 = Dodge
4057-5908 = Parry
5909-10000 = Hit

If you had 16.43% Block as a Warrior for example, everything would be the same except after Parry it would be
5909-7551 = Block
7552-10000 = Hit

Yes, you do get benefit from decimals. There's more on this topic in this thread; over 100% avoidance
Anyway, that's pretty much how it works.

[Tarigar]

Source: tuffmuffin /roll 1-10000 = combat table

The reason I asked is everyone always uses the 1-100. Then they include decimals so even if it is .01-100.00 it still is 10000 which is a huge difference and the potential outcomes just exponentially increased.

[Molohk]

You can gain avoidance in decimals. Having 25.5% dodge means you will probably dodge 255 hits out of every 1000 hits. I'm not sure how many decimals Blizzard uses in combat table calculations, but to give you an idea, the cap on parry is 47.003525%, so I suspect Blizzard uses six decimals in their combat table calculations.

And I apologized because my post had a lot to do with programming, and not much to do with avoidance and DR. I didn't mean to imply that YOU hijacked the thread, and I'm not a back-seat mod.

[Tarigar]

Source: Molohk You can gain avoidance etc...

Naw it helped clarify things and 100 roll combat system is a lot different then a 10000 roll combat system .

[Satrina]

It's a pretty safe bet that if the game holds two decimals for display, the table goes to 10000

[Superspy23]

Understanding programming helps alot with understanding stuff like this so you're input is likely enlightening to some. I seem to remember back in BC days someone actually auto attacked and tracked the percentage of all results for a few days straight (I think he used unarmed to prevent weapon breaks from skewing the data). He did this because it's the best way to get a better view of the RNG as it relates to your stats after the decimal; use a ridiculously huge sample size. While it's not infallible it did go a long way to supporting the 10000 roll system relative to the attack table.

[Wars]

Wow, great reading this through again after a while and glad to see we have at least somewhat a concensus about the number of decimals on the avoidance DR.

A long huge sample size is the best way obviously to get the most precise numbers, the larger the sample size, the closer you are going to get to realistic numbers that you can likely see over a period of time. Thanks Satrina and Super

[Doormat]

Why would they use 10000 discrete roll values and not just use the IEEE double (or float). It makes no sense that they would use an RNG (which operates in the binary system I assume) and then convert it to a discrete value from 1-10000 (base 10). Unless anyone has evidence otherwise I would assume they use double floating point precision for a random roll.

[jere]

most rand functions generate an integer value. They typical method for adjusting that to your desired range is some kind of modulation scheme (which is still integer based).

So you would do something *like*
combat_roll = rand() % 10000

Converting to floating point there would add a significant amount of overhead since integer operations tend to take a lot less CPU cycles than floating point operations. I would guess they would stick to integer values at this point and only convert to IEEE 32/64 at the end where the conversion has the least amount of processing impact.

The avoidance percentages for your character are most likely floating point numbers for sure. What you would do, is, whenever your combat table is updated, multiply all avoidance values by 100 (to get them to the 10000's place) at that point to keep from having to do it later on the fly when combat rolls are introduced to compare with.

That's all oversimplified mind you as they probably use a proprietary random number generator to cut down on processing time and guarantee a more uniform distribution, but in general, most rand() functions produce a discrete result rather than floating point. Off the top of my head, I believe Java has support for floating point random numbers, but most of your more common languages for this type of application, like C/C++ use an integer version.

[Doormat]

Source: jere most rand functions generate an integer value. They typical method for adjusting that to your desired range is some kind of modulation scheme (which is still integer based). So you would do something *like* combat_roll = rand() % 10000 Converting to floating point there would add a significant amount of overhead since integer operations tend to take a lot less CPU cycles than floating point operations. I would guess they would stick to integer values at this point and only convert to IEEE 32/64 at the end where the conversion has the least amount of processing impact. The avoidance percentages for your character are most likely floating point numbers for sure. What you would do, is, whenever your combat table is updated, multiply all avoidance values by 100 (to get them to the 10000's place) at that point to keep from having to do it later on the fly when combat rolls are introduced to compare with. That's all oversimplified mind you as they probably use a proprietary random number generator to cut down on processing time and guarantee a more uniform distribution, but in general, most rand() functions produce a discrete result rather than floating point. Off the top of my head, I believe Java has support for floating point random numbers, but most of your more common languages for this type of application, like C/C++ use an integer version.

By far the most commonly used C/C++ random function is drand48() which is in the math.h header. This returns a type double. Java also returns something of type double as well.

[jere]

Source: Doormat By far the most commonly used C/C++ random function is drand48() which is in the math.h header. This returns a type double. Java also returns something of type double as well.

I don't think that is standard C/C++. It isn't the ansi documentation that I can tell. Perhaps it is a c function in a particular flavor of linux?

These are the standard c headers:
The C Standard Library - stdlib.h
The C Standard Library - math.h

I don't think most applications will be using it since it is not readily available in most compilers (looks like mostly some linux flavors that I can tell). The overhead of using floating point numbers would be a burden anyways for applications of this nature. Still it is neat to see some cool functions like that out there. I may have to pop up another linux install and play with it.

EDIT: but this is pretty offtopic, we shoud probably split this discussion off somewhere else.

[Molohk]

I've done programming in a lot of languages, and 90% of the pseudorandom number generators I've seen return a floating point number. The only pseudorandom integer number generator I can remember is rand() in C stdlib.h, which returns an integer value between 0 and RAND_MAX. Rand() is a part of ANSI C and it is very efficient compared to floating point functions, so it's quite possible that Rand() is used on real-time games to reduce processing load.

[Satrina]

Whether their combat table random function returns 9048 or .9048 is completely academic. Those numbers are never transmitted across the network, so packing integer vs. float for transmission is not a concern. Maybe they use integer types, maybe they use float types, hard to say from here. Maybe the combat table is a specially crafted struct to save space since there are so many of them instantiated at any given moment. That may have dictated the type used more than anything.


edit: oops, I perpetuate the offtopic

[Satrina]

And I fix

[Satrina]

Speaking of random algorithms, that's a thought problem I have had bouncing in my head for a while about MMO games in general. Normally you wouldn't touch rand() or any of the typical PRNG algorithms with a 10 foot pole for something like this, and you'd use one of the cryptographic PRNG algorithms.

However, if you take into account the sheer volume of requests for random numbers, and use a singleton random generator for the server -- can you get away with a crappy and very deterministic PRNG like rand()?