Type | Ref | Zero based |
Coin | coin | |
1 Dice | ||
4 sided | [ 1d4 ] | |
6 sided | [ 1d6 ] | |
8 sided | [ 1d8 ] | |
10 sided | [ 1d10 ] | Y |
12 sided | [ 1d12 ] | |
20 sided | [ 1d20 ] | Y |
2 Dice | ||
6 sided | [ 2d6 ] | |
10 sided | [ 2d10 ] | |
5 Dice: | ||
6 sided | [ 5d6 ] |
Description on values from PixelVixen?:
The information you're reading is a 32 bit unsigned integer. The leftmost two bits are ignored, and the other 30 bits are divided into 5 sections, one for each roll. (Yes, this means that max number of dice we can support at this time is 5.)
The rightmost 6 bits signify the 1st die, 2nd rightmost 6 bits signify the value of the 2nd die... etc etc leaving the leftmost two bits empty.
You also have to keep in mind that some of these things are zero based. So when you roll a 6 on a 1d6, on the back end, you may have actually rolled a 5, given the option of anything between 0-5, inclusive. If you're clever and read the aconf files, you may be able to figure out which ones are zero based and which ones aren't. :)
When there's only one die involved, then it is pretty easy to read because all the bits left of the roll are set to 0. But when there's more than one die, then you'll have to do some bitwise arithmetic.
Using one of Russy's examples (original inquirer in the forums), let's say you roll 4,1, and the persistentSimulatorState? gives you a 68 for the roll. What does this mean? Stick 68 on your windows default calculator. (make sure you choose scientific mode) Now click on the "Bin" (binary) radio button on the left side. You should get 1000100. Since it's two dice, you break it down into two sections, 6 bits each, which gives us:
die 1: 000100 die 2: 000001
Now pop these numbers in binary mode and then switch to Dec (decimal) and you'll see that it indeed shows 4, 1