On Sunday, November 1, 2020 at 3:01:48 AM UTC+3, MK wrote:
> Last week I decided to play 100 matches of 17 points against XG
> using my own external dll. On my 11th match, I had to reboot my
> PC when I was only a dozen moves into the first game.
>
> When I restarted XG, after a few moves, I just rolled the dice
> in a hurry instead of doubling and I thought I noticed that the
> dice sequence wasn't the same.
>
> I stopped, restarted to double check and sure enough the rolls
> were different depending on if I doubled. So, I tried 7 times
> exporting and comparing the moves, as below, to see what was
> going on. After I doubled, for the following two turns the rolls
> were different but synchronized again afterwards.
>
> Altering my checker moves or XG's doubling didn't do anything.
> Only my doubling caused it. The source code, (with some simple
> beeps inserted to hear when the DLL was called), to my dice
> roller is at the bottom, along with instructions to compile it
> and a link to my EXE.
>
> The DLL beeped for the different rolls also, which means that
> XG fetched the rolls from it, cached and skipped a few to roll
> its own numbers before fetching from the DLL again.
>
> This is eerie. Perhaps something to do with being haloween.. ;)
> Check the below sequences, do your own tests, etc. and let me
> know what you find out if anything different or the same.
>
> MK
>
> ============================================================
> After the first sequence, I only pasted event time and the rolls
> to save space.
>
> ; [Player 1 "XG Roller++"]
> ; [Player 2 "Murat 17"]
> ; [EventDate "2020.10.31"]
> ; [EventTime "15.45"]
> 17 point match
> Game 1
> Murat 17 : 0 XG Roller++ : 0
> 1) 65: 24/13 66: 24/18(2) 13/7(2)
> 2) 22: 13/11(2) 6/4(2) 32: 13/8
> 3) 21: 13/11 6/5 64: 8/2 6/2
> 4) 43: 24/20 8/5 54: 8/4 6/1
> 5) 21: 11/8 33: 18/15(2) 13/10(2)
> 6) 62: 20/14 8/6 Doubles => 2
> 7) Takes 61: 10/4 6/5
>
> ; [EventTime "15.47"]
> 1) 65: 13/7 8/3 66: 24/18*(2) 13/7(2)
> 2) Doubles => 2 Takes
> 3) 41: Bar/20 Doubles => 4
> 4) Takes 63: 13/7 8/5*
>
> ; [EventTime "15.48"]
> 1) 65: 24/13 66: 24/18(2) 13/7(2)
> 2) 22: 13/11(2) 6/4(2) 32: 13/8
> 3) 21: 13/11 6/5 64: 8/2 6/2
> 4) 43: 11/4 54: 13/9 13/8
> 5) 21: 24/22 4/3 33: 8/5(2) 6/3*(2)
> 6) Doubles => 2 Takes
> 7) 41: Bar/21 4/3 53: 9/4* 7/4
> 8) 53: Cannot Move 43: 18/15 8/4
> 9) 64: Cannot Move 62: 18/10
> 10) 21: ????
>
> ; [EventTime "15.51"]
> 1) 65: 13/7 8/3 66: 24/18*(2) 13/7(2)
> 2) 22: Bar/23 24/22 13/11 6/4 Doubles => 2
> 3) Takes 32: 6/3* 3/1*
> 4) 21: Bar/23 Bar/24* 64: Bar/21* 13/7
> 5) 43: Bar/21 24/21 54: 18/13 18/14*
> 6) Doubles => 4 Takes
> 7) 62: Bar/23 13/7 11: 21/20 7/5 6/5
> 8) 43: ????
>
> ; [EventTime "16.01"]
> 1) 65: 13/7 8/3 66: 24/18*(2) 13/7(2)
> 2) 22: Bar/23 24/22 13/11 6/4 Doubles => 2
> 3) Takes 32: 6/3* 3/1*
> 4) 21: Bar/23 Bar/24* 64: Bar/21* 13/7
> 5) 43: Bar/21 6/3 54: 18/13 18/14*
> 6) Doubles => 4 Takes
> 7) 62: Bar/23 21/15 11: 14/13 7/5 6/5
> 8) 43: ????
>
> ; [EventTime "17.00"]
> 1) 65: 24/13 66: 24/18(2) 13/7(2)
> 2) 22: 24/20 6/4(2) 32: 8/5* 7/5
> 3) 21: Bar/22 Doubles => 2
> 4) Takes 64: 13/7 6/2
> 5) 43: 13/6 54: 8/3* 6/2
> 6) 21: Bar/22* 33: Bar/22 7/4(2) 6/3*
> 7) 62: Cannot Move 61: 22/16 4/3
> 8) 31: Bar/21* 41: Bar/24 8/4*
> 9) 65: Cannot Move 33: 16/4
> 10) 53: Cannot Move 44: 18/10(2)
>
> ; [EventTime "17.04"]
> 1) 65: 24/13 66: 24/18(2) 13/7(2)
> 2) 22: 24/20 6/4(2) 32: 8/5* 7/5
> 3) 21: Bar/22 Doubles => 2
> 4) Takes 64: 13/7 6/2
> 5) 43: 13/6 54: 8/3* 6/2
> 6) Doubles => 4 Takes
> 7) 31: Bar/22* 22/21 41: Bar/24 8/4*
> 8) 65: Cannot Move Doubles => 8
> 9) Takes 33: 18/15(2) 7/4(2)
> 10) 53: Bar/17 44: 24/16 15/11(2)
> 11) 66: 17/5 13/7(2) 22: 16/14 11/5
>
> ============================================================
>
> Here is the c code:
>
> #include <windows.h>
> #include <stdlib.h>
> #define WINAPI __stdcall
>
> int seed=0;
> int die1, die2, dise;
> int WINAPI DllMain( int hModule, int ul_reason_for_call, void *lpReserved )
> {
> switch( ul_reason_for_call )
> {
> case DLL_PROCESS_ATTACH:
> beep (500,1500);
> }
> return 1;
> }
>
> __declspec( dllexport ) int Dice(void)
> {
> if (seed == 0)
> {
> seed = 11117;
> srand(seed);
> beep (500,500);
> }
> die1 = rand();
> die2 = rand();
> dise = ((die1 % 6) + 1) * 8 + ((die2 % 6) + 1);
> beep (700,400);
> return dise;
> }
>
> ============================================================
>
> Unless you already have a C compiler, here is a link to "TinyC
> Compiler" which is portable and only requires 1.5Mb of disk space.
>
> https://en.wikipedia.org/wiki/Tiny_C_Compiler
>
> Save my above code to a text file xyz.c and create another text
> file xyx.def with these lines:
>
> LIBRARY xyz.dll
> EXPORTS
> Dice
>
> And compile it using the command:
>
> .\tcc xyz.c -shared
>
> Then point to it from XG's external dice settings.
>
> ============================================================
>
> With a little trust and virus scanning, you can download my
> executable directly from this link:
>
> https://www.montanaonline.net/backgammon/mkdice.bin
>
> (Server doesn't allow .dll just rename it after you download).
>
> ============================================================
>
> MK

Hello,

I wrote a DLL which roles dices and writes the result to extreme gammon window title for 750 milliseconds. It means, you can check that extreme gammon cheats or not :)

you can download the compiled DLL -->

https://mega.nz/file/mNYmAaSb#hgKPIIFZI3utyuWXEEWmFmHMIm84J-Ju6JlpcHn5LTI

If you interest with source code, I can share it.

Regards,

On August 11, 2022 at 11:19:30 AM UTC-6, Ahmet Ecevit wrote:

> I wrote a DLL which roles dices and writes the
> result to extreme gammon window title for 750
> milliseconds. It means, you can check that
> extreme gammon cheats or not :)

Whether your DLL intercepts XG's dice rolls or
produces its own dice rolls, I don't understand
how does displaying the rolls briefly in the title
prove anything about anything? Can you explain
more?

> If you interest with source code, I can share it.

Yes, please do share.

Feeding dice rolls to XG from another process is
the next best thing to playing with manual dice.

Michael had once tried it but his EXE had timing
problems or something and never worked right.

Maybe you can compile your DLL into an EXE to
try this again and hopefully have better success.

I would be very interested in seeing this done. If
you don't want to do it and if I can use your code,
I may be willing to tackle it myself.

MK

On Saturday, August 13, 2022 at 11:52:48 AM UTC+3, MK wrote:
> On August 11, 2022 at 11:19:30 AM UTC-6, Ahmet Ecevit wrote:
>
> > I wrote a DLL which roles dices and writes the
> > result to extreme gammon window title for 750
> > milliseconds. It means, you can check that
> > extreme gammon cheats or not :)
> Whether your DLL intercepts XG's dice rolls or
> produces its own dice rolls, I don't understand
> how does displaying the rolls briefly in the title
> prove anything about anything? Can you explain
> more?
> > If you interest with source code, I can share it.
> Yes, please do share.
>
> Feeding dice rolls to XG from another process is
> the next best thing to playing with manual dice.
>
> Michael had once tried it but his EXE had timing
> problems or something and never worked right.
>
> Maybe you can compile your DLL into an EXE to
> try this again and hopefully have better success.
>
> I would be very interested in seeing this done. If
> you don't want to do it and if I can use your code,
> I may be willing to tackle it myself.
>
> MK

Send your email address to ahmetecevit@hotmail.com

On August 17, 2022 at 5:53:21 AM UTC-6, Ahmet Ecevit wrote:

> On Saturday, August 13, 2022 at 11:52:48 AM UTC+3, MK wrote:

>> Yes, please do share.

> Send your email address to ahmet...@hotmail.com

I did send you an email address that you can use
to send your source code but it would be better
if you could share it here also since other people
may be interested in and can benefit from it too.
That's a purpose/advantage of communicating
publicly in forums instead of privately. Thanks.

MK

On August 13, 2022 at 2:52:48 AM UTC-6, MK wrote:

> Feeding dice rolls to XG from another process is
> the next best thing to playing with manual dice.
>
> I would be very interested in seeing this done. If
> you don't want to do it and if I can use your code,
> I may be willing to tackle it myself.

I posted my simple sample code and ideas in a new thread:

https://groups.google.com/g/rec.games.backgammon/c/AFza_Ms4aIM/m/_Vp9slQmBQAJ

MK

Xg tends to give itself the ginroll too often when you do a blunder +0.10 and up . I have a 1 point match recorded against it where i didn't enter a single time in 6 rolls in a row with 4 of them it having 3 points , and 2 of them 2 points in its inner board. Probability of that happening is very very very ; low . It tends to bend the dice sometimes so it is true .

snj5j5sn schrieb am Freitag, 21. April 2023 um 07:27:02 UTC+2:
> Xg tends to give itself the ginroll too often when you do a blunder +0.10 and up . I have a 1 point match recorded against it where i didn't enter a single time in 6 rolls in a row with 4 of them it having 3 points , and 2 of them 2 points in its inner board. Probability of that happening is very very very ; low . It tends to bend the dice sometimes so it is true .

Very convincing proof. I'm sure no one here has ever seen such a sequence in reality with real dice.
More serious: If you could explain why someone should invest 1000s of hours to do a bot and cheat when someone with just some basic statistical background can prove cheating in half an hour and ruin your work and reputation?

Naturally you maybe be better than the pro player that haven't realized cheating yet.

On April 22, 2023 at 10:16:52 AM UTC-6, Frank Berger wrote:

> snj5j5sn schrieb am 21. April 2023 um 07:27:02 UTC+2:

>> Xg tends to give itself the ginroll too often when
>> you do a blunder +0.10 and up .... i didn't enter in
>> 6 rolls ... Probability of that happening is very
>> very very; low.

> Very convincing proof.

I wondered why you hadn't participated in this
thread earlier but better late than never... ;)

> I'm sure no one here has ever seen such a
> sequence in reality with real dice.

Here you are defeating your own exaggerated
strawman argument. He didn't say "no one here
has ever seen such a sequence" but he more
reasonably said "Probability of that happening
is very very very; low".

Ironically, you would have been indeed correct
if you had said that such sequences would be
more common with "real dice" than with RNG
dice (that, BTW, he was talking about) because
many RNG's smooth out the dispersion and the
distribution of the dice in the nale of leveling
luck...

> More serious: If you could explain why someone
> should invest 1000s of hours to do a bot and cheat
> when someone with just some basic statistical
> background can prove cheating in half an hour and
> ruin your work and reputation?

1- You doen't need to spend 1000s of hours to do
a cheating bot. You can steal someone else's code
for a cheating bot and spend only 500 hours. ;)

2- If you haven't noticed, the title of this thread is
"cheating, err teaching" not only for the pun of the
anagram but because it would make perfect sense
for BG bots that are claimed to be training tools to
cheat in order to teach. When tarining an animal or
a gamblegammon player, the reward or punishment
needs to be immediate for the animal or gambler to
make the connection. Thus the previous poster's
claim is not only perfectly possible but may indeed
be more likely/common than not.

3- During this thread, I have demonstrated that Ex-Gee
makes multi-threaded AND multiple call to the external
dice DLL per dice roll and/or cube decision, providing
sample code for you all to prove it to yourselves. Many
times since then, I asked from bot developers like you
for possible reasons why a bot would do that. It's very
possible that you haven't read any of them and it's also
possible that you won't have read this post and will
deprive us all from your deep knowledge of software
development... ;)

MK