info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
XG/XG2 and External Random Number Generators (random.org etc)
67 views
Skip to first unread message
Michael Petch
Apr 16, 2012, 1:26:15 PM4/16/12
to
One question I get asked a lot about XG is whether there is a way to use
random.org or other random number generator with XG/XG2. The Answer is
actually yes, although it isn't completely obvious. This is documented
under XG's help in the section "External Dice".
The section describes the mechanism by which a programmer can create a
new source of randomness for dice rolls during match play, however there
are a few example ones installed with XG, one of which is numbers from
random.org.
To do this, go to the "Options" menu, "Settings" menu, "Main Settings"
tab. At the bottom there is "External Dice Generator". Click on the
radio button to select it. You must now select a DLL. TO the right of
the DLL box there is a "..." (or a folder with green arrow) button.
Click that. XG generally displays the directory it is installed into. In
the short list of files is a folder called "dice dll". Double click it.
There are a few entries but one should see "randomorg.dll". Double click
to choose it. Click "Apply" button and then "Ok".
If for some reason there is a failure in the external random number
generator (It isn't available or returns values that aren't between 1
and 6) it will pop up a box when there is an error warning you, and then
it reverts back to the internal dice generator. If that happens you have
to go back and select the external dice source again as described above.
There are two other samples. One is dicelib.dll and it uses the Borland
random number generator (Not recommended), and an implementation of
Mersenne Twister (mt199937.dll).
If you are a programmer, source code for the examples can be found in
the same directory and help on the programmers API is available in XG's
online help under "External Dice" as well.
random.org or other random number generator with XG/XG2. The Answer is
actually yes, although it isn't completely obvious. This is documented
under XG's help in the section "External Dice".
The section describes the mechanism by which a programmer can create a
new source of randomness for dice rolls during match play, however there
are a few example ones installed with XG, one of which is numbers from
random.org.
To do this, go to the "Options" menu, "Settings" menu, "Main Settings"
tab. At the bottom there is "External Dice Generator". Click on the
radio button to select it. You must now select a DLL. TO the right of
the DLL box there is a "..." (or a folder with green arrow) button.
Click that. XG generally displays the directory it is installed into. In
the short list of files is a folder called "dice dll". Double click it.
There are a few entries but one should see "randomorg.dll". Double click
to choose it. Click "Apply" button and then "Ok".
If for some reason there is a failure in the external random number
generator (It isn't available or returns values that aren't between 1
and 6) it will pop up a box when there is an error warning you, and then
it reverts back to the internal dice generator. If that happens you have
to go back and select the external dice source again as described above.
There are two other samples. One is dicelib.dll and it uses the Borland
random number generator (Not recommended), and an implementation of
Mersenne Twister (mt199937.dll).
If you are a programmer, source code for the examples can be found in
the same directory and help on the programmers API is available in XG's
online help under "External Dice" as well.
xduf...@gmail.com
Apr 16, 2012, 4:51:41 PM4/16/12
to
dicelib.dll interest lies in the fact it implements a delay in releasing the dice to the caller (XG).
This allows to show that the program does not fetch the dice in advance. You can see that XG made its decision of doubling or not doubling before the dice were roll. during a checker play you can see that dice are are not requested during the analyze but only when they really need to be rolled.
This allows to show that the program does not fetch the dice in advance. You can see that XG made its decision of doubling or not doubling before the dice were roll. during a checker play you can see that dice are are not requested during the analyze but only when they really need to be rolled.
Michael Petch
Apr 16, 2012, 5:34:54 PM4/16/12
to
On 16/04/2012 2:51 PM, xduf...@gmail.com wrote:
> dicelib.dll interest lies in the fact it implements a delay in releasing the dice to the caller (XG).
>
> This allows to show that the program does not fetch the dice in advance. You can see that XG made its decision of doubling or not doubling before the dice were roll. during a checker play you can see that dice are are not requested during the analyze but only when they really need to be rolled.
I was aware of this. I did something similar (popping up the dice before
> dicelib.dll interest lies in the fact it implements a delay in releasing the dice to the caller (XG).
>
> This allows to show that the program does not fetch the dice in advance. You can see that XG made its decision of doubling or not doubling before the dice were roll. during a checker play you can see that dice are are not requested during the analyze but only when they really need to be rolled.
they are returned to Snowie) for that exact same reason (To prove that
there is no lookahead). This was using the old SnowieDice.dll many moons
ago. In that case one had to write a proxy DLL that intercepted all the
regular Snowie calls, pass them to Snowie's DLL and then delayed
returning them with a pop up box prior to Snowie receiving them.
Michael Petch
Apr 16, 2012, 6:23:03 PM4/16/12
to
One thing I am curious about. People can still claim that the "internal"
dice generator in XG2 is looking ahead since there is no way to
intercept those calls (I know this is not the case for other reasons).
The claim can be made that the internal generator does something
entirely different. Any thought given to moving the internal generator
(for standard dice rolling) into a DLL entirely so that it too can be
entirely replaced?
dice generator in XG2 is looking ahead since there is no way to
intercept those calls (I know this is not the case for other reasons).
The claim can be made that the internal generator does something
entirely different. Any thought given to moving the internal generator
(for standard dice rolling) into a DLL entirely so that it too can be
entirely replaced?
muratk
Apr 17, 2012, 1:19:27 AM4/17/12
to
On Apr 16, 4:23 pm, Michael Petch <mpe...@capp-sysware.com> wrote:
.
I wish posts like this one were more common in RBG, instead of the
mere parroting of shallow/valueless arguments.
While at it, why not consider also externalizing the dll for reading
from text files?
To its credit XG already uses an external dll for fetching dice from
random.org
MK
.
mere parroting of shallow/valueless arguments.
While at it, why not consider also externalizing the dll for reading
from text files?
To its credit XG already uses an external dll for fetching dice from
random.org
MK
Michael Petch
Apr 17, 2012, 1:23:10 AM4/17/12
to
On 16/04/2012 11:19 PM, muratk wrote:
> While at it, why not consider also externalizing the dll for reading
> from text files?
>
I'll be publishing a DLL tomorrow that supports reading text files. The
> While at it, why not consider also externalizing the dll for reading
> from text files?
>
DLL can be used with Snowie 3 and 4 and XG2/3 (Allowing both to read
from a file). The DLL will support reading the text files produced by
sites like random.org; GNUBG's diceroll output, and Snowie's export dice
to file feature.
Michael Petch
Apr 17, 2012, 1:24:43 AM4/17/12
to
On 16/04/2012 11:23 PM, Michael Petch wrote:
XG2/3
Oops XG1/2 not XG2/3 lol.
XG2/3
Oops XG1/2 not XG2/3 lol.
0 new messages