Proof XG is cheating, err teaching, even when using external DLL?

[MK]

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

[ah...Clem]

On 10/31/2020 8:01 PM, MK wrote:


[crap snipped]


Didn't you hear? All "X bot cheats with the dice" threads have been
moved over to Bill Robertie's site.

Please post at
https://forumserver.twoplustwo.com/138/backgammon-forum-hosted-bill-robertie/merge-eliminate-rigtard-threads-1780302/

Thanks.

[Michael]

On Sunday, November 1, 2020 at 2:01:48 AM UTC+2, MK wrote:
>
> die1 = rand();
> die2 = rand();

I am not familiar with C but it looks to me you should change the code to
die1 = rand()% 6;
die2 = rand()% 6;
and adjust the rest of the code.

[Paul Epstein]

No because he uses die1 % 6 later in the code.
You can go mod 8 to find the second dice and divide by 8 to find the first
die. So far the code looks ok.

As Billy Joel would say.

Mod by 6 first thing.
Or mod by 6 last thing.
It's still random dice to me.

Paul

[Michael]

Is there a possibility (die1 % 6) would output zero?

[MK]

On November 1, 2020 at 3:37:57 PM UTC-7, Michael wrote:

> I am not familiar with C but it looks to me you
> should change the code to
> die1 = rand()% 6;
> die2 = rand()% 6;
> and adjust the rest of the code.

As Paul already responded to you, the code is okay.
Do you remember the thread "External dice DLLs with
various BG bots" back in March (that only you had
actively participated in)?

It's the same problem. Anyone interested should read
at least the first and the fifth articles in:

https://groups.google.com/d/msg/rec.games.backgammon/63L0OCwNWbI/XMsTxlA6BQAJ

The code is essentially the same except for setting
the seed differently to prevent it from being reset
after XG detaching and attaching process again for
some mysterious reason.

The rand() function was already fixed to be thread
independent long time ago, so XS's detaching and
attaching thread countless times wasn't causing any
problems but today I tested and verified again using
a single thread anyway just in case.

The beeps are a crude way of doing it but serve their
purposes well enough. The seed gets set only once.

In our previous discussion above, we had lost interest
and didn't pursue it any furher. On my side, because
it looked like changing where the seed was set solved
the problem with reproducing same dice sequences. But
it wasn't. I only noticed it again by chance because
I happened to notice the dice sequence changed when I
replayed differently.

Playing against different skill levels of XG doesn't
make a difference. But, after testing quite a few more
times, I see that it's actually worse. The sequence
sometimes changes without the human doubling, it doesn't
synchronize back as I first thought but the deviating
sequence can be repeated somewhat consistently also.

Anyway, I'm not going to waste much of my time to find
out what's going on. I think it's good enough of me to
show something is not right. And I don't think anyone
else here will pluck his head out his dumb ass to want
and try to figure it out either...

MK

[Paul Epstein]

Yes, that's why the code says (die1 % 6) + 1 and why Billy Joel says

[Michael]

On Monday, November 2, 2020 at 3:04:52 AM UTC+2, MK wrote:
> I think it's good enough of me to
> show something is not right.

> MK

Obviously!
I am sure you already know the DLL doesn't work, and the reason mght be the compiler. The code does output these numbers persistently though:
46 46 50 19 18 12 51 36 41 19 30 22 9 28 14 43 29 28 38 50

> Anyway, I'm not going to waste much of my time to find
> out what's going on.

If so, then who is going to prove that XG is cheating ... erm teaching?? :-)

[MK]

On November 2, 2020 at 11:23:38 AM UTC-7, Michael wrote:

> On November 2, 2020 at 3:04:52 AM UTC+2, MK wrote:

>> I think it's good enough of me to
>> show something is not right.

> Obviously!
> I am sure you already know the DLL doesn't work,
> and the reason mght be the compiler. The code
> does output these numbers persistently though:

> 46 46 50 19 18 12 51 36 41 19 30 22 9 28 14.....

It's because the seed is set to a constant.
Change it. Recompile. It will roll different numbers.

One problem some people like you here have is that
you can't recognise when people know what they are
talking about and give them the due credit. :( Maybe
because you guys don't know what you are talking about??

>> Anyway, I'm not going to waste much
>> of my time to find out what's going on.

> If so, then who is going to prove that XG is cheating
> ... erm teaching?? :-)

How about you? I got it started. Maybe you can finish it?

Come to think of it, gnubg may have had the same problem
and its developers took out the external dice feature
because of that.

It never made sense to me why would a bot developer drop
a useful, desirable feature that was previously added for
a good reason??

Being based on stolen code, XG may have simply inherited
the problem??

Since XG doesn't allow user selected seeds in any of the
external dll's that come with it, nobody could ever tell
whether it rolled the same sequences for the same seeds... ;)

And that may explain why XG never had the user selectable
seed feature, eh...?

MK

[Michael]

On Monday, November 2, 2020 at 10:35:29 PM UTC+2, MK wrote:
>
>
> One problem some people like you here have is that
> you can't recognise when people know what they are
> talking about and give them the due credit. :( Maybe
> because you guys don't know what you are talking about??
>

Ah.. Murat the greatest making the greatest assumptions ever.
My knowledge of the C mostrosity is almost zero, but at least I know how to do a few tests.
To do these
a)I modified the code to output the first 20 numbers of the seed band write them in a file.
I gave you the numbers before:46 46 50 19 18 12 51 36 41 19 30 22 9 28 14 43 29 28 38 50
b)I did the same for the DLL. It outputs totally different numbers for each run.
bi)First run
number die1 die2
46 6 5
54 6 6
41 1 5
53 5 6
49 1 6
17 1 2
bii)Second run
number die1 die2
46 6 5
54 6 6
10 2 1
10 2 1
25 1 3
17 1 2
41 1 5
43 3 5
42 2 5
11 3 1
54 6 6
35 3 4
18 2 2
49 1 6
44 4 5
46 6 5
38 6 4
30 6 3
11 3 1
44 4 5
29 5 3
49 1 6
21 5 2
12 4 1
44 4 5
49 1 6
30 6 3
34 2 4
44 4 5
51 3 6
54 6 6
43 3 5
49 1 6
35 3 4
26 2 3
46 6 5
14 6 1
35 3 4
44 4 5
52 4 6
26 2 3
29 5 3
36 4 4
17 1 2
29 5 3
19 3 2
36 4 4
13 5 1
22 6 2
45 5 5
33 1 4
35 3 4
19 3 2

Now all you have to do is check whether the bot took those numbers from the
DLL or wherher it created them itself. If it created them itself then the bot cheated. If it got them from the mulfunctioning DLL then it did not.

So what's the answer Murat?

Here's the code for you to check.
****************************************


#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#define WINAPI __stdcall
#define DATA_SIZE 100

int seed=1;
int die1, die2, dice;

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 == 1)
{
seed = 11117;
srand(seed);
// beep (500,500);

}


die1 = rand();
die2 = rand();

dice = ((die1 % 6) + 1) * 8 + ((die2 % 6) + 1);
//beep (700,400);
FILE * fPtr;
fPtr = fopen("c:\\users\\mike\\desktop\\tcc\\file1.txt", "a");
fprintf(fPtr,"%d ", dice, "\r\n");

fclose(fPtr);

return dice;

}

[Michael]

Remember to change the path in the code.

fPtr = fopen("c:\\users\\mike\\desktop\\tcc\\file1.txt", "a");

One solution to the problem is to make the DLL read a file containing
already existing random numbers.
And since it actually communicates with the bot correctlly, then pass those numbers to the bot.
What do you think?

[MK]

On November 3, 2020 at 4:40:26 AM UTC-7, Michael wrote:

> One solution to the problem is to make the DLL read
> a file containing already existing random numbers.
> And since it actually communicates with the bot
> correctlly, then pass those numbers to the bot.
> What do you think?

I'm ahead of you Michael. I had already tried it last
time. I used the million roll files from BGBlitz site
to not just read but also write the rolls just to make
sure. Trust me, I know a little about debugging, testing,
breaking, etc. software.

It seemed to work fine but I hadn't tried to vary my
moves and cude decisions, etc. Without that, simple
rand() roller seemed to work fine also at that time.

But how's that going to help you? If you are going to
claim that there is a problem with the compiler and
the dll, how does it matter what the code actually is?

But, anyway, here is the code I had used. Have fun. ;)

MK

=====================================================
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>

#define WINAPI __stdcall

int die1, die2, dise;
long rptr, wptr;
FILE *txtf;
FILE *cntf;

int WINAPI DllMain( int hModule, int ul_reason_for_call, void *lpReserved )
{
switch( ul_reason_for_call )
{
case DLL_PROCESS_ATTACH:

txtf = fopen("C:\\....\\.....\\dice1.txt", "r");

if(txtf == NULL)
{
beep(900,900);
exit(0);
}

cntf = fopen("C:\\....\\.....\\dicep.txt", "a+");

if(cntf == NULL)
{
beep(900,900);
exit(0);
}

while (fscanf(cntf, "%lu", &rptr) != EOF) {
wptr = rptr;
}

fseek(txtf, wptr, SEEK_SET);

break;

case DLL_THREAD_ATTACH:

break;

case DLL_THREAD_DETACH:

break;

case DLL_PROCESS_DETACH:

beep(900,900);

wptr = ftell(txtf);
fclose(txtf);

fprintf(cntf, "%lu\n", wptr);
fclose(cntf);

break;

}

return 1;
}

__declspec( dllexport ) int Dice(void)
{

if (feof(txtf)) {
rewind(txtf);
fscanf(txtf, "%u", &dise);
}
fscanf(txtf, "%u", &dise);
die1 = dise % 10;
fprintf(cntf, "%u\n", dise);
fprintf(cntf, "%u\n", die1);
fscanf(txtf, "%u", &dise);
die2 = dise / 10;
fprintf(cntf, "%u\n", dise);
fprintf(cntf, "%u\n", die2);

dise = die1 * 8 + die2;
beep(1600,100);

return dise;
}

[MK]

On November 3, 2020 at 4:19:30 AM UTC-7, Michael wrote:

> On November 2, 2020 at 10:35:29 PM UTC+2, MK wrote:

>> One problem some people like you here have is that
>> you can't recognise when people know what they are
>> talking about and give them the due credit. :( Maybe
>> because you guys don't know what you are talking about??

> Ah.. Murat the greatest making the greatest
> assumptions ever.

> a)I modified the code to output the first 20 numbers
> of the seed band write them in a file.
> I gave you the numbers before:46 46 50 19 18 12 51 36
> 41 19 30 22 9 28 14 43 29 28 38 50
> b)I did the same for the DLL. It outputs totally
> different numbers for each run.

I didn't assume anything. In your previous post you
said:

"The code does output these numbers persistently though:

"46 46 50 19 18 12 51 36 41 19 30 22 9 28 14 43 29 28 38 50

Now you are saying it outputs different numbers for
each run. I can't follow... Which is it?

> Here's the code for you to check.

What was wrong with my code??
BTW: I had used the varible "dise" because the DLL's
external function name is "Dice". Just in case... 99%
of the time things like this may not matter but you
need to pay attention as a good practice.

MK

[Michael]

On Tuesday, November 3, 2020 at 2:28:12 PM UTC+2, MK wrote:
>
>
> I didn't assume anything. In your previous post you
> said:
>
> "The code does output these numbers persistently though:
> "46 46 50 19 18 12 51 36 41 19 30 22 9 28 14 43 29 28 38 50
>
> Now you are saying it outputs different numbers for
> each run. I can't follow... Which is it?

When I said the code I meant the code of the *.c file.

>
> What was wrong with my code??

Nothing was wrong. The problem was that the created DLL was malfunctioning for some unknown reason - which again was not your fault.It just produced unknown numbers.

The problem was that you didn't check whether the bot was getting those numbers from the malfuntioning DLL or not.
And you were hasty enough to accuse the bot of cheating, when in reality it was getting the numbers from the bad DLL.

Furthermore since you were ahead of me and re-designed the DLL to take numbers from file, why didn't you come back and retract your claims??
Imo you did that on purpose to come back a few months later saying you provided proof, the the bot worshippers etc etc..

>I decided to play 100 matches of 17 points against XG
>using my own external dll.

100!? Wow
I would faint just playing 2!
Grunty calls it "masturbating with the bots" :-)
Good luck anyway.

[Nasti Chestikov]

I have Xtreme Gammon on my pc upstairs only. So, on my laptop, start Toolwiz TimeFreeze, install XtremeGammon and play using your dll:

; [Site "eXtreme Gammon"]
; [Match ID "-643935724"]
; [Player 1 "XG Roller+"]
; [Player 2 "Nasti"]
; [Player 1 Elo "2262.00/400"]
; [Player 2 Elo "1700.00/0"]
; [EventDate "2020.11.04"]
; [EventTime "08.34"]
; [Variation "Backgammon"]
; [Unrated "Off"]
; [Crawford "On"]
; [CubeLimit "1024"]

25 point match

Game 1
Nasti : 0 XG Roller+ : 0
1) 65: 24/13 21: 13/11 6/5
2) 65: 24/13 66: 24/18(2) 13/7 11/5
3) 65: 13/2 62: 8/2 6/4
4) 11: 6/5(3) 2/1 53: 8/3 7/4
5) 43: 13/6 42: 13/7
6) 64: 13/3 65: 13/8 13/7
7) 43: 6/3 5/1 33: 18/15(2) 8/5 7/4
8) 53: 13/5 41: 8/3
9) 54: 13/4 51: 6/1 5/4
10) 44: 13/9 13/5 8/4 53: 15/12 15/10
11) 54: 9/4 8/4 51: 10/5 7/6
12) Doubles => 2 Takes
13) 32: 8/6 3/Off 66: 12/Off 6/Off(2)
14) 66: 6/Off(3) 5/Off 53: 5/Off 3/Off
15) 63: 5/Off 3/Off 51: 5/Off 1/Off
16) 55: 5/Off(2) 4/Off(2) 42: 4/Off 2/Off
17) 52: 4/2 4/Off 21: 3/Off
18) 62: 2/Off 1/Off 41: 6/5 4/Off
19) 64: 1/Off
Wins 2 point

Now stop Toolwiz TimeFreeze and reboot.

Then start Toolwiz TimeFreeze, install XGammon and play again using your dll:

I'm assuming the dice rolls should be the same? Because they're not......

; [Site "eXtreme Gammon"]
; [Match ID "-643937755"]
; [Player 1 "XG Roller+"]
; [Player 2 "Nasti"]
; [Player 1 Elo "2262.00/400"]
; [Player 2 Elo "1700.00/0"]
; [EventDate "2020.11.04"]
; [EventTime "09.03"]
; [Variation "Backgammon"]
; [Unrated "Off"]
; [Crawford "On"]
; [CubeLimit "1024"]

25 point match

Game 1
Nasti : 0 XG Roller+ : 0
1) 65: 24/13 32: 24/21 13/11
2) 44: 8/4*(2) 6/2(2) 22: Cannot Move
3) Doubles => 2 Drops
Wins 1 point

[Michael]

On Wednesday, November 4, 2020 at 11:12:58 AM UTC+2, Nasti Chestikov wrote:
> On Tuesday, 3 November 2020 at 20:46:58 UTC, Michael wrote:

>
> I have Xtreme Gammon on my pc upstairs only. So, on my laptop, start Toolwiz TimeFreeze, install XtremeGammon and play using your dll:
>

Whose DLL? MY DLL???

Be careful to who you are replying. It's not mine. Murat made it.

>
> I'm assuming the dice rolls should be the same? Because they're not......
>

Yep that's what we are saying all this time. Been an experienced programmer yourself you should be able to explain why. We suspect the srand() malfunctions when compiled to a DLL using the tcc compiler, because the exact same code when used in a *.c file works perfectly.
Can you at least complile Murat's DLL on your own compiler and provide the file?
This would at least solve the question whether the problem is due to the tcc compiler or not.

[Nasti Chestikov]

On Wednesday, 4 November 2020 at 12:32:31 UTC, Michael wrote:
> Whose DLL? MY DLL???
>
> Be careful to who you are replying. It's not mine. Murat made it.
> >

Apologies, still getting used to the "new and improved" Google Groups layout....

> Can you at least complile Murat's DLL on your own compiler and provide the file?
> This would at least solve the question whether the problem is due to the tcc compiler or not.

No I cannot. Well, actually I can compile it but ExtremeGammon bellyaches about it not being in the right format or something and so conveniently reverts to its own internal RNG.

[Michael]

Today I went to my warehouse where there's an old computer (runs on Win98 and Win XP) just in case I may have to look at my customers' database. I always carry a backup of my important files plus my desktop files on a USB stick.
Checked your code on WinXP and it worked perfectly. Your code outputs the same numbers percistently!!
So the problem is obviously the operating system.

Here's the fastest solution I came up. I have tried it on Winows 7 and it works fine. It just resets the seed every time there's a call from the bot and delivers the 1st, 2nd, 3rd,..nth number of roll.

#include <windows.h>
#include <stdlib.h>
#define WINAPI __stdcall

int die1, die2, dise, i=1, turn=1;

__declspec( dllexport ) int Dice(void)

{

srand(11117);
for (i = 1; i < turn; ++i)
{

die1 = rand();
die2 = rand();
}

dise = ((die1 % 6) + 1) * 8 + ((die2 % 6) + 1);
++turn;

return dise;
}

[MK]

On November 3, 2020 at 1:46:58 PM UTC-7, Michael wrote:

> On November 3, 2020 at 2:28:12 PM UTC+2, MK wrote:

>> What was wrong with my code??

> Nothing was wrong. The problem was that the created
> DLL was malfunctioning for some unknown reason

DLL functions just fine. It's the XG that does weird
things while fetching dice.

> The problem was that you didn't check whether the bot
> was getting those numbers from the malfuntioning DLL

I did.

> And you were hasty enough to accuse the bot of
> cheating, when in reality it was getting the numbers
> from the bad DLL.

DLL is not bad. XG is bad.

> Furthermore since you were ahead of me and re-designed
> the DLL to take numbers from file, why didn't you come
> back and retract your claims??

I pre-answered that in the same post. Pay attention.

>> I decided to play 100 matches of 17 points against
>> XG using my own external dll.

> 100!? Wow
> I would faint just playing 2!

I did many long experiments before like the 100 matches
of 25 points in April-June 2012, and others against Gnubg
Grandmaster that you can see at:

https://www.montanaonline.net/backgammon/gb.php

> Grunty calls it "masturbating with the bots" :-)

I couldn't agree more. I think I may have even likened it
to precticing with an inflatable dolls in order to become
good lovers with humans...

> Good luck anyway.

Well, I kind of lost the feeling for it, since I can't
use my own external dice, etc.

MK

[MK]

On November 5, 2020 at 1:02:49 PM UTC-7, Michael wrote:

> Checked your code on WinXP and it worked perfectly.
> Your code outputs the same numbers percistently!!
> So the problem is obviously the operating system.

> Here's the fastest solution I came up. I have tried
> it on Winows 7 and it works fine.

Unless you mean that you ran XG in WinXP and Win7 to
use my "code", you are not following proper process
of elimination and wasting your time.

The DLL works just fine in Win10 also. Modify your
own code you posted on November 3, 2020 to do write
some number of rolls to a file when XG calls the DLL
for the first time, like this:

=====================================================

__declspec( dllexport ) int Dice(void)
{

if (seed == 1) {
seed = 11117;
srand(seed);

FILE * fPtr;
fPtr = fopen("c:\\users\\mike\\desktop\\tcc\\file1.txt", "a");

for (i = 1; i < 50; ++i) {

die1 = rand();
die2 = rand();

dice = ((die1 % 6) + 1) * 8 + ((die2 % 6) + 1);

fprintf(fPtr,"%d ", dice, "\r\n");
}
fclose(fPtr);
}
return dice;
}

=====================================================

You will see that there is nothing wrong with Tiny-C
compiler, or the DLL, or Window10. You will get the
same numbers every time you start XG. Obviously it's
XG that is doing something more than just fetching
dice rolls from the DLL.

Why are you so averse to me? Why are you so stubborn
to be in denial??

If you had tried as hard to figure out what XG is doing,
you may have made some progress by now.

However, very unlikely since XG source code is not public
and the compiled XG code is encrypted by copy protection.

Maybe some butt buddies of XG developers can ask them???

Yet, thay may not help either since they may have stolen
the code from elsewhere and may not have mastery of the
code themselves to know what it does... ;( [sad wink]

BTW; does anyone know when gnubg dropped the external
dice DLL feature. I have all version somewhere and I can
figure out but maybe someone can save me time and effort.

MK

[Michael]

You are NOT communicating Murat!
YOUR CODE should output these numbers to XG when the seed is set to 11117.
46 46 50 19 18 12 51 36 41 19 30 22 9 28 14 43 29 28 38 50. This is CONFIRMED.Period.
These numbers correspond to these rolls:
65 65 26 32 22 41 36 44 15 32 63 62 11 43 61 35 53 43 64 26.

From you very first post you said these are not the rolls the bot gets/produces.
I proved to you and even gave you the code in this message
https://groups.google.com/d/msg/rec.games.backgammon/sxlOCjtvAIM/s805vAStAgAJ
to check it yourself: that the bot DOES INDEED get the numbers from the DLL, and that the problem is the DLL, not XG.


You are now saying that the DLL works fine on any operating system.
What's your definition of fine?? For me "fine" means to output the exact same numbers of the SEED and do this every time it starts. Wasn't this your problem all along?

Solution 1: Use a windows XP machine. Your original code will produce the rolls mentioned above.
Solution 2: On any other operating system use the code I gave you here:
https://groups.google.com/d/msg/rec.games.backgammon/sxlOCjtvAIM/QC9bgGkIAAAJ

******************************
Btw I am not averse to you. There are some points I agree with you. (e.g. that XG is mostly a copy of GNU).
But I can't agree with your fixation that the bots cheat. I would agree though in case you provided solid evidence.
You made me waste my time learning what the C mostrosity does, just to provide you evedince that your claim is false. Sorry about that.

And now you still insist that it's XG that pushes the DLL to malfunction!!!
Next thing you will imagine is that XG calls all the spirits of hell when installed on Win7 or Win10, but does not do the same when installed on WinXP because the latter has been proclaimed a Saint by the Catholic Church. :-)

[MK]

On November 6, 2020 at 4:11:12 AM UTC-7, Michael wrote:

> You are NOT communicating Murat!

Trust me I'm trying. You're the only one who is seems
to be putting a genuine effort in this discussion and
I value it.

> You are now saying that the DLL works fine on any
> operating system.

You claimed that it was either the DLL, or the Tiny-C
compiler or Windows10. Then you said you did some tests
on your WinXP and Win7 machines but it's not clear to
me what did you exactly do. I didn't test anything on
WinXP or Win7. With my last suggested changes to your
own code, I tried to show you that the DLL itself works
consistently in Windows10 also.

> What's your definition of fine?? For me "fine" means
> to output the exact same numbers of the SEED and do
> this every time it starts. Wasn't this your problem
> all along?

Yes, XG fetches different numbers from the same DLL and
the same seed.

> You made me waste my time learning what the C mostrosity
> does, just to provide you evedince that your claim is
> false. Sorry about that.
>
> And now you still insist that it's XG that pushes the DLL
> to malfunction!!!

No. As indicated by the question mark at the end of this
threads title, I was trying to demonstrate that XG wasn't
fetching the same numbers using the same DLL and the same
seed, and questioning what could be the reasons for this
suspicious behavior.

Now, let's forget about monstrous C codes, compilers, etc.
Let's do this with whatever language you feel comfortable
with, in order to not waste any more of your and my time
on this.

Create DLL using the rand() function to produce dice rolls.

Create simple EXE to call that DLL to fetch 100 dice rolls
and to write them to a text file.

Run your EXE a few times each on WinXP, Win7 and Win10 to
see if it produces the same sequences consistently using
your DLL. (Win10 alone would be good enough for my purposes).

Play a few games against XG each on WinXP, Win7 and Win10,
using your DLL and restarting XG before each game. Make sure
you vary your moves from game to game, especially double at
least once. Save the game records and compare the dice rolls
to the ones produces by your own simple EXE above.

Let us know what you find out.

If you want us to duplicate your results, just put your EXE
and DLL where we can download from, to test on our machines.

Personally, I wouldn't even care to see your source codes but
you may post them here if you feel they may be useful for the
discussion.

Fair enough request? With your favorite programming language,
this should take you minimal time and effort.

MK

[Nasti Chestikov]

http://www.mediafire.com/file/7az2qpyuzhq90pk/Dice.7z/file

Pascal version, it's a zip file so you should be good to download without worrying about Nasti's in there (see what I just did?) :-)

There's a dll and the source. The source is crude:

library NastiSameSequence;

{$mode objfpc}{$H+}

var
RandomizeAlreadyCalled: Boolean = False;

function Dice: Integer; {$ifdef windows}stdcall{$else}cdecl{$endif};
var
D1, D2: Integer;
begin
// call randomize once and never again.
if not RandomizeAlreadyCalled then begin
RandSeed := 201066;
RandomizeAlreadyCalled := True;
end;

D1 := Random(6) + 1;
D2 := Random(6) + 1;

Result := D1 * 8 + D2;
end;

exports
Dice;

begin
end.

You can download Lazarus and compile it if you're so inclined but this is 100% the code used to create the dll.

I haven't included an EXE to retrieve x rolls from it.

[MK]

On November 7, 2020 at 12:20:32 AM UTC-7, Nasti Chestikov wrote:

> Pascal version, it's a zip file so you should be good
> to download without worrying about Nasti's in there

I have an isolated PC just for this kind of stuff...

> (see what I just did?) :-)

What? Did you misspell "nasties"? ;)

> There's a dll and the source. The source is crude:

> I haven't included an EXE to retrieve x rolls from it.

Okay, but have you tested it with XG?

BTW: I meant to reply to your previous post to tell you
how you can keep testing XG for 14 days forever in more
easy ways but I didn't have time. I may do it later.

MK

[Nasti Chestikov]

I played two games and the rolls were the same.

However, I'll play an extended set later and vary my plays.......

[Nasti Chestikov]

Here's an alternative to using an EXE to interrogate the dll.

Copy and paste this

Var i : Longint;
Var D1, D2: Integer;
Var RandomizeAlreadyCalled: Boolean = False;

begin

if not RandomizeAlreadyCalled then begin
RandSeed := 201066;
RandomizeAlreadyCalled := True;
end;

Randomize;
For i :=1 to 1000 do begin

D1 := Random(6) + 1;
D2 := Random(6) + 1;

Writeln (D1,',',D2);
end;
end.

into https://www.onlinegdb.com/online_pascal_compiler and run the code - there's an option on the screen at the top of the output window to copy it to clipboard - you can then paste into your favourite spreadsheet and voila, 1000 dice rolls which can then be checked against what dice XG rolls using the dll.

This method means we have used two different Pascal compilers to generate (hopefully) the same dice rolls so any variances in XG's rolls can't be attributable to a dodgy compiler :-)

This is essentially what the dll does except it doesn't doesn't do the whole D1*8*D2 which is what XG is expecting.

[Nasti Chestikov]

So I've played 4 games comprising of 113 rolls:

; [Site "eXtreme Gammon"]
; [Match ID "-644247766"]

; [Player 1 "XG Roller+"]
; [Player 2 "Nasti"]
; [Player 1 Elo "2262.00/400"]
; [Player 2 Elo "1700.00/0"]

; [EventDate "2020.11.07"]
; [EventTime "11.27"]

; [Variation "Backgammon"]
; [Unrated "Off"]
; [Crawford "On"]
; [CubeLimit "1024"]

15 point match

Game 1
Nasti : 0 XG Roller+ : 0

1) 51: 24/23 13/8
2) 53: 8/3 6/3 33: 8/5(2) 6/3(2)
3) 51: 24/18 Doubles => 2
4) Drops Wins 1 point



Game 2
Nasti : 0 XG Roller+ : 1
1) 32: 24/21 13/11 62: 24/18 6/4*
2) 62: Bar/23 13/7* 65: Bar/14*
3) 42: Bar/21* 13/11* 63: Bar/22
4) 63: 13/10 13/7 52: Bar/20 22/20
5) 61: 21/15 11/10 21: 13/10*
6) 61: Bar/18 63: 13/7* 10/7
7) 33: Bar/22 23/20 6/3(2) 53: 8/3* 6/3
8) 21: Bar/23 24/23 64: 24/14
9) 42: 8/4 6/4 21: 7/5* 6/5
10) 65: Cannot Move Doubles => 2
11) Drops Wins 1 point



Game 3
Nasti : 0 XG Roller+ : 2
1) 32: 24/21 13/11 61: 13/7 8/7
2) 63: 11/5 8/5 52: 24/22 13/8
3) 41: 24/20 21/20 64: 24/18 22/18
4) 66: 20/8(2) 52: 8/3 6/4
5) Doubles => 2 Takes
6) 44: 13/9(2) 8/4(2) 61: 13/7 4/3
7) 65: 9/4 9/3 42: 8/4 6/4
8) 41: 6/2 3/2 54: 13/9 13/8
9) 53: 6/1 4/1 44: 9/5 8/4(2) 7/3
10) 51: 6/5 6/1 54: 7/2 6/2
11) 21: 6/4 5/4 64: 7/1 5/1
12) 62: 8/6 8/2 42: 6/2 4/2
13) 52: 6/1 4/2 53: 6/1 4/1
14) 65: 13/2 31: 4/3 4/1
15) 65: 13/2 55: 18/8(2)
16) 65: 5/Off(2) 21: 8/5
17) 11: 1/Off(4) 32: 8/5 2/Off
18) 61: 4/Off 2/1 55: 5/Off(2) 3/Off(2)
19) 31: 4/Off 32: 3/Off 2/Off
20) 61: 4/Off 1/Off 31: 3/Off 1/Off
21) 61: 2/1 2/Off 51: 2/Off 1/Off
22) 61: 2/Off 1/Off 41: 2/Off 1/Off
23) 61: 2/1 2/Off Doubles => 4
24) Drops Wins 2 point



Game 4
Nasti : 0 XG Roller+ : 4
1) 31: 8/5 6/5 32: 24/22 13/10
2) 32: 13/8 51: 10/5 6/5
3) 64: 8/2 6/2 33: 13/7(2)
4) 64: 13/3* 62: Cannot Move
5) 55: 13/3 6/1*(2) 21: Cannot Move
6) Doubles => 2 Takes
7) 54: 13/8 6/2 22: Cannot Move
8) 51: 13/7 52: Cannot Move
9) 11: 24/23 8/6 7/6 21: Cannot Move
10) 41: 23/22 8/4 11: Cannot Move
11) 65: 22/11 53: Cannot Move
12) 21: 24/22 4/3 41: Bar/21
13) 41: 8/4* 4/3 22: Cannot Move
14) 31: 22/21 11/8 54: Bar/21
15) 53: 21/16 8/5 31: Cannot Move
16) 42: 16/10 54: Bar/21 13/8
17) 65: 10/5 6/Off 64: 13/7 8/4
18) 65: 6/Off 5/Off 52: 21/16 8/6
19) 53: 5/Off 3/Off 43: 16/12 7/4
20) 32: 5/3 5/2 32: 21/18 8/6
21) 54: 3/Off(2) 43: 18/11
22) 62: 3/Off 2/Off 54: 11/6 7/3
23) 52: 3/Off 2/Off 53: 8/5 7/2
24) 51: 2/Off 1/Off 42: 6/4 6/2
25) 65: 2/Off 1/Off
Wins 4 point

These 113 rolls are exactly the same as I generated on https://www.onlinegdb.com/online_pascal_compiler (as described in an earlier post):

5,1
5,3
3,3
5,1
2,3
2,6
2,6
6,5
2,4
3,6
6,3
5,2
6,1
1,2
6,1
6,3
3,3
3,5
2,1
6,4
2,4
1,2
5,6
2,3
1,6
3,6
5,2
4,1
6,4
6,6
5,2
4,4
6,1
5,6
2,4
1,4
5,4
3,5
4,4
5,1
4,5
2,1
6,4
6,2
2,4
5,2
3,5
6,5
3,1
6,5
5,5
5,6
1,2
1,1
3,2
1,6
5,5
1,3
3,2
6,1
3,1
6,1
5,1
1,6
1,4
1,6
1,3
3,2
2,3
1,5
6,4
3,3
4,6
6,2
5,5
2,1
4,5
2,2
5,1
5,2
1,1
2,1
1,4
1,1
5,6
5,3
2,1
1,4
1,4
2,2
3,1
5,4
3,5
3,1
4,2
4,5
6,5
4,6
5,6
2,5
3,5
3,4
2,3
2,3
4,5
4,3
6,2
5,4
2,5
5,3
1,5
4,2
6,5

So nothing suspicious to report I'm afraid (as much as I'd like there to be) :-)

[Michael]

On Saturday, November 7, 2020 at 9:20:32 AM UTC+2, Nasti Chestikov wrote:
>
> http://www.mediafire.com/file/7az2qpyuzhq90pk/Dice.7z/file
>

Nice!
Since you already uploaded a working DLL, I guess I should do the same.

Here, Murat guaranteed to provide the same random numbers according to your chosen seed 11117.It's written in C and gave you the code before.

I am skeptic by nature and I joined this discussion for the 1 in a million possibility that XG might be cheating.

https://drive.google.com/file/d/1YKMCS0rrUJxYhNCJn9PRjoIgzC-neOaI/view?usp=sharing

[MK]

On November 7, 2020 at 12:20:32 AM UTC-7, nasti.c...@gmail.com wrote:

> RandSeed := 201066;

> You can download Lazarus and compile it if you're so inclined
> but this is 100% the code used to create the dll.

I only used Object Pascal a few times eons ago; not enough to
remember. So, while I was trying to look up about it, I saw your
seeking help in a beginners forum for dice roller code. Are you
proficient with Pascal? If so, maybe we can ask a favor from you
to improve your dice roller DLL and EXE, accepting user input
for seed, etc. If not, can you recompile your above code using
the same seed as Michael to if C and Pascal roll the same dice?

MK

[MK]

On November 7, 2020 at 7:10:23 AM UTC-7, Michael wrote:

> Here, Murat guaranteed to provide the same random numbers
> according to your chosen seed 11117.It's written in C and gave
> you the code before.

This has turned into a case of "can take horses to the water but
can't make them drink"... But I will still continue the discussion
as anything is better than discussing positions. We have posted
many versions of codes. Can you post one more time the exact
code you used so that I can compile it myself also.

So far, this is what I know: there is no problem with the Tiny-C
compiler. You can run the DLL to write 100 dice rolls to a file
100 times and it's the same. If you fetch the dice from a buffer,
table or file, XG also rolls the same dice consistently, at least
in long enough sequences that we will probably never notice if
it didn't anyway. The problem seems to be with fetching dice
rolls one at a time from XG, for whatever reason that is with
XG's doing.

> I am skeptic by nature and I joined this discussion for the 1 in
> a million possibility that XG might be cheating.

Whether cheating or not, it seems to be doing something fishy,
probably inherited from its primitive Jellyfish ancestors. :) Let
me clarify again that I'm not saying bots are unbeatable because
they cheat. They are routinely beatable after you train at it long
enough. Personally, if I was peedling as "teaching" bot, I would
make it as "cheating" as BG books are "cheating", in "teaching"
quickly. Who would want to play against a non "cheating" bot
"teaching" slowly over 10 years... ;(

MK

[Michael]

> Can you post one more time the exact
> code you used so that I can compile it myself also.
>

> MK
The exact code is here:

https://groups.google.com/g/rec.games.backgammon/c/sxlOCjtvAIM/m/QC9bgGkIAAAJ

[MK]

On November 29, 2020 at 12:46:18 PM UTC-7, Michael wrote:

>> Can you post one more time the exact
>> code you used so that I can compile it myself also.

> The exact code is here:
> https://groups.google.com/g/rec.games.backgammon/c/sxlOCjtvAIM/m/QC9bgGkIAAAJ

In that post, you say: "It just resets the seed every time there's
a call from the bot", which totally misses the point of this thread,
which is that the bot fails to roll the same sequence of numbers
for the same seed that is set only once for each execution of XG.

Why are we having such a difficulty communicating..?? You must
be in total denial and defense to not even make a genuine effort
to understand the issue. Or maybe you try but can't, in which case
I won't offend you by calling you idiot, etc. out of compassion... ;)

MK

[Michael]

The issue is that you are making assumptions that were already proven groundless by Nastis' DLL which is basically identical to your original code written in another programming language. There are a lot of issues about the use of srand in C, google it....

[Nasti Chestikov]

About 30 years ago I was using Borland Turbo Pascal and was proficient enough to be able to write an AI routine for a human vs cpu Spades card game.

However, as with all things in life, if you don't use you lose. My knowledge of Pascal these days is limited.

However you can download my 7-Zip file from http://www.mediafire.com/file/vlo6vzj71rb83ly/Dice.7z/file

The zip file contains 3 DLLs and 3 lots of associated source code.

NastiFixed = the dice are not random, they are fixed as a 4-3 roll.
NastiNoDouble = the dice will never roll a double
NastiGenuineSameSequenceWithBeep11117 = seed is set to 11117 (as per request) and the program will beep every time a dice roll is generated

The first two are a good test of whether XG is doing it's own thing as, say, a double generated from the NastiNoDouble dll should raise warning flags.

You can always download Lazarus from https://www.lazarus-ide.org/ if you want to compile the source yourself / improve on it.

[Nasti Chestikov]

if you go to https://www.onlinegdb.com/online_pascal_compiler and paste in

Var i : Longint;
Var D1, D2: Integer;
Var RandomizeAlreadyCalled: Boolean = False;

begin

if not RandomizeAlreadyCalled then begin

RandSeed := 11117;
RandomizeAlreadyCalled := True;
end;
//Randomize;

For i :=1 to 1000 do begin

D1 := Random(6) + 1;
D2 := Random(6) + 1;

Writeln (D1,',',D2);
end;
end.

You can generate 1000 dice rolls and copy them to clipboard. The dice rolls for this seed are
1,6
6,5
5,6
2,3
3,3
3,4
5,6
4,5
1,5
4,3
2,2
4,1
2,6
1,4
5,4

2,1
4,2
5,6
4,2
6,2

3,1
4,2
3,6
1,4
5,5
2,3
1,4
4,2
2,2
2,1
2,5
1,6
6,3
4,2
5,2
6,2
6,1
6,1
1,3
6,4
4,2
3,5
4,3
4,5
1,1
3,5
1,6
6,3
4,4
4,6
4,1
4,3
3,3
1,5
5,6
6,4
3,3
2,1
4,3
3,2
4,2
3,1
1,1
1,1
2,6
5,1
6,1
2,5
5,4
5,5
2,5
6,1
4,4
3,6
5,4
5,3
6,6
5,3
6,5
4,6
2,4
3,2
3,4
4,5
5,1
1,5
3,4
3,3
1,3
1,2
6,2
2,3
1,1
5,5
3,1
4,3
3,1
3,3
5,6
2,3
2,5
2,3
6,6
3,1
6,3
2,6
1,2
1,6
5,5
5,1
5,4
2,4
5,5
4,5
3,6
3,4
2,4
5,3
3,1
1,4
6,5
4,5
6,3
2,3
3,1
5,1
2,3
3,5
3,1
3,6
4,2
4,1
1,1
2,2
6,4
5,1
4,2
2,5
3,6
1,2
3,3
4,2
6,4
4,6
6,2
4,3
6,1
4,2
4,6
1,1
1,5
4,4
4,4
1,1
6,3
3,1
3,3
3,2
1,4
4,3
2,5
6,2
6,2
3,3
2,5
5,4
6,1
3,3
6,1
4,3
1,5
5,4
4,4
1,6
5,5
5,4
3,2
1,6
2,1
5,5
2,6
3,5
5,6
6,2
5,2
5,5
3,3
6,4
2,2
5,2
5,3
2,6
6,2
2,3
4,3
5,4
1,3
2,3
1,6
1,1
2,1
4,1
4,5
1,2
4,4
5,3
1,4
6,6
6,4
6,6
1,6
6,3
3,4
4,4
5,4
1,4
6,3
2,1
6,5
5,4
1,6
3,1
5,2
4,4
5,5
1,4
2,4
3,1
3,6
4,2
4,2
3,5
6,6
4,4
3,4
3,6
3,4
4,1
2,2
5,2
6,6
6,4
4,1
1,3
6,1
4,3
1,6
3,2
1,4
1,1
3,3
2,5
1,6
5,6
5,5
5,2
4,1
4,2
3,2
1,1
3,3
4,6
5,3
6,1
5,3
3,1
1,4
1,1
1,2
5,6
1,3
3,5
4,6
6,1
4,3
5,1
3,2
2,5
6,3
6,2
2,1
6,4
6,6
4,2
4,1
3,6
1,3
1,5
2,5
6,4
6,4
4,3
5,2
3,1
1,6
4,1
4,2
2,2
2,2
3,1
3,3
6,6
1,1
5,5
6,2
6,1
6,5
5,6
5,3
4,1
2,6
6,6
4,4
6,3
2,3
6,1
2,2
4,1
6,4
6,5
1,1
5,4
1,5
2,1
1,6
2,1
2,5
1,6
5,1
2,3
1,5
2,5
3,3
4,1
2,4
4,5
3,3
6,6
6,2
5,5
5,2
5,3
6,1
3,4
6,3
6,3
6,1
5,4
1,1
4,2
6,5
5,3
2,3
4,2
1,4
5,3
5,5
4,6
4,1
2,6
6,3
4,5
4,2
2,2
6,6
6,4
2,2
4,1
3,6
5,5
2,6
6,4
6,2
5,6
5,2
4,1
1,1
4,6
1,6
6,2
4,6
5,6
1,2
2,6
2,4
5,1
3,3
4,5
4,5
6,4
6,4
5,3
5,3
2,3
5,4
2,6
6,3
2,5
4,2
6,3
3,2
2,3
2,2
3,1
6,3
2,1
5,2
1,2
3,4
5,4
5,1
6,6
6,6
6,3
2,6
5,1
5,1
3,6
1,6
2,4
5,4
6,1
2,1
1,6
5,2
5,2
6,2
1,3
1,6
3,2
3,6
1,3
3,4
1,2
1,5
2,6
4,4
4,5
2,6
6,4
1,6
6,2
6,6
3,1
1,5
4,3
5,4
6,6
2,6
2,2
1,3
4,1
2,6
5,6
1,2
4,2
3,4
2,5
6,5
4,5
5,1
1,1
2,2
6,5
1,1
1,2
4,4
3,3
2,3
3,3
2,1
6,6
5,5
6,4
4,6
4,3
3,5
4,3
5,2
2,6
5,5
1,4
4,3
6,5
6,5
6,4
1,1
4,5
2,5
1,4
6,2
4,6
5,2
1,1
2,3
1,3
4,4
6,2
3,2
1,5
1,5
5,6
3,1
1,4
6,5
6,1
6,5
2,4
2,6
5,5
3,1
4,2
2,4
2,4
2,2
5,1
3,6
4,2
2,4
5,1
6,2
2,1
3,5
1,2
2,1
6,6
3,4
4,2
1,3
1,5
4,6
5,2
3,3
2,5
4,1
6,3
3,1
2,3
4,1
5,5
2,6
3,3
1,1
4,6
5,2
2,6
5,2
3,6
4,4
3,1
2,1
6,3
5,5
5,5
4,1
1,5
4,5
1,5
1,6
3,2
1,6
6,1
5,1
1,6
2,4
1,3
2,5
2,5
1,1
2,3
4,1
4,1
3,5
3,2
6,6
4,6
2,3
5,6
4,2
5,6
4,4
2,2
2,2
5,4
5,1
6,1
5,6
5,6
1,1
6,1
3,6
2,5
3,4
5,6
2,6
4,5
5,6
1,2
4,4
5,5
1,5
1,3
3,5
6,4
3,6
1,2
1,4
6,6
2,3
4,5
1,4
2,5
5,6
4,2
1,3
1,2
4,6
2,2
4,1
2,1
4,3
1,1
1,4
4,5
5,2
2,5
4,3
5,6
6,3
3,5
3,5
2,6
6,1
4,3
3,3
5,2
3,1
4,3
1,4
2,5
2,3
2,4
4,5
2,3
1,2
3,5
4,5
1,6
2,3
3,3
6,4
1,1
6,3
1,3
5,1
5,1
1,1
6,6
1,6
2,4
4,2
3,6
6,1
5,6
6,4
1,2
2,3
4,2
5,2
3,4
6,6
2,2
5,2
2,2
4,2
3,5
3,6
2,1
4,2
6,1
6,3
2,5
5,6
5,1
2,6
3,1
3,3
1,5
4,5
1,6
5,5
6,1
4,2
2,1
3,6
2,2
2,2
3,3
1,3
1,3
1,3
2,5
2,1
3,5
5,3
5,3
6,4
4,6
4,6
5,5
2,2
4,4
4,2
5,4
2,6
4,6
3,5
2,3
3,4
1,6
3,5
2,6
5,6
4,6
1,2
3,4
2,5
4,4
1,2
1,6
6,6
6,4
3,4
2,5
3,4
4,1
4,5
5,6
3,5
5,5
2,1
2,6
6,4
6,4
6,1
5,6
6,4
1,5
2,2
2,2
2,3
1,4
2,5
1,3
1,4
2,5
2,6
1,6
2,4
3,4
5,5
6,5
1,3
2,4
4,2
5,3
1,6
3,4
1,4
2,3
1,5
1,2
4,5
4,3
3,5
1,4
5,3
1,4
6,1
4,3
3,2
1,3
1,2
3,5
6,4
3,6
2,1
6,4
1,4
4,3
6,6
4,5
5,6
2,3
3,3
2,3
1,3
2,5
4,1
1,2
2,5
3,4
4,1
3,3
4,4
3,2
1,3
6,4
2,1
3,4
6,1
1,3
5,2
2,6
2,2
3,5
5,1
6,3
6,3
1,2
3,3
4,4
1,1
4,1
3,4
1,4
6,3
6,2
2,3
2,3
1,5
4,2
2,1
4,4
5,3
2,2
3,3
6,2
2,6
6,3
1,1
5,5
6,2
3,3
2,2
4,5
5,6
2,5
2,6
1,4
3,1
1,1
2,4
1,6
1,6
4,6
3,4
5,1
3,1
6,5
4,6
6,5
3,1
6,5
5,3
3,5
1,4
2,3
1,2
3,5
2,2
6,6
3,3
2,3
1,1
3,2
3,4
5,2
5,4
4,2
3,2
2,4
6,4
5,2
4,2
3,2
5,3
4,4
4,1
3,4
4,5
2,6
1,5
6,1
4,4
3,3
1,1
5,4
2,6
3,4
1,6
1,5
4,1
4,2
2,2
4,5
6,1
6,5
2,4
2,6
5,1
1,3
1,4
5,6
2,1
3,5
2,1
6,6
5,1
1,6
4,3
5,5
4,6
4,3
1,2
3,3
6,6
3,2
4,1
3,6
2,1
3,5
1,6
5,4
5,2
3,6
4,1
5,1
5,3
4,1
3,2
3,5
4,3
2,3
5,6
6,1
1,3
2,2
4,3
3,2
6,2
6,5
2,5
3,1
6,1
3,3
3,1
5,1
2,5
6,2
1,3
4,4
4,6
2,1
5,3
4,6
1,1
1,1
3,3
6,2
2,3
1,2
4,5
5,2
6,4
3,6
2,1
2,4
5,5
5,4
3,1
3,1
1,4
6,4
5,2
4,5
1,4
3,5
2,1
3,3
5,3
5,6
4,6
1,2
4,6
5,6
2,3
1,1
3,6
2,5

[MK]

On November 30, 2020 at 6:45:50 AM UTC-7, Michael wrote:

> The issue is that you are making assumptions that were already
> proven groundless by Nastis' DLL which is basically identical to
> your original code written in another programming language.

"Basically identical" is not identical and "another programming
language" can make a big difference. (I will expand more on
this later, in my reply to Nasti).

> There are a lot of issues about the use of srand in C, google it....

I already had many times during this discussion. All I found were
complaints from beginners that rand() always produced the same
number either because they never call srand() or always call it with
the same seed just before rand(), and such...

If you have found anything else relevant to the subject here, would
you be kind enough to paste just a couple of those "a lot of" issues
that you are referring to??

MK

[MK]

On December 1, 2020 at 4:20:34 AM UTC-7, nasti.c...@gmail.com wrote:

> About 30 years ago I was using Borland Turbo Pascal and was
> proficient enough to be able to write an AI routine for a human
> vs cpu Spades card game.

Interesting coincidence. Let me reminisce a little. Also about 30
years ago (1993), I had singlehandedly developed a real estate
multiple listing software using Borland Paradox. At a time when
most MLS software ran on multiuser Xenix, with monochrome
dumb terminals connecting via 2400 baud modems, I had the
first software that had color pictures of properties, agents, etc.
with color inkjet/laser reports, running on PC's, downloading
instant updates from a PC server, via 2400 baud modems. It
had taken me 4 months to develop from scratch and it was
good enough that I was able to sell the server for $10,000,
office versions for $1,000 and agent versions for $500. But I
was more interested in living a country life, raising horse, goats,
chickens, etc. and didn't have the drive nor right connections to
make more out of it. It was called "Realty Vision". Eventually big
players developed similar software as mine has gone out of use
because the local MLS dissolved. Years later, many other products
and web sites used the name "Realty Vision"... Makes me feel sad :(
yet satisfied :)

> NastiFixed = the dice are not random, they are fixed as a 4-3 roll.

I had done the same earlier. It always rolled the same number but
this isn't relevant to my subject here.

> NastiNoDouble = the dice will never roll a double

This I haven't tried. Interesting idea though. On the other hand,
I tried not so perfectly "distributed" rolls to see what effect it
would have (suspecting that it would favor the human). These
aren't relevant to my subject here either.

> NastiGenuineSameSequenceWithBeep11117 = seed is set to 11117
> (as per request)

Thanks. It wasn't really necessary but I just wanted to compare anyway.

> The first two are a good test of whether XG is doing it's own thing as,
> say, a double generated from the NastiNoDouble dll should raise warning flags.

Yes, useful tests in a different way but they don't help with the question
why XG is making questionable calls to the dice DLL, that causes it to
lose the state of the RNG.

MK

[MK]

On December 1, 2020 at 6:21:39 AM UTC-7, nasti.c...@gmail.com wrote:

> .....

> D1 := Random(6) + 1;
> D2 := Random(6) + 1;
> Writeln (D1,',',D2);

> .....

> The dice rolls for this seed are
> 1,6
> 6,5
> 5,6

Sheesh! It took some scrolling down to get to the end of your post :(

Two things:

1- Your code doesn't check when and why the DLL is called. I looked
up a little to give you some tips on how to do it. Here is a discussion:

https://forum.lazarus.freepascal.org/index.php?topic=24916.0

2- Per the documentation, FreePascal uses Mersenne Twister algorithm
for random() function.

https://www.freepascal.org/docs-html/rtl/system/random.html

Obviously, the numbers don't match C rand() but nor Mersenne Twister
mt19937ar, which XG seems to be using. There are probably a dozen
version of Mersenne Twister algorithm and the numbers not matching
is not really relevant at all.

What's matters is that Mersenne Twister is not affected by XG's erratic
calling of the DLL since numbers come from an indexed table.

So, FreePascal won't help with testing dice sequesnces but you can at
least add logic to your code to test when and why it's called, if you are
curious about it.

MK

[Nasti Chestikov]

Apologies my DLL's couldn't add weight to your argument, there's a sadistic part of me that would bloody love to catch XG with it's grubby little fingers in the cash register :-)

[MK]

On December 2, 2020 at 3:35:28 AM UTC-7, nasti.c...@gmail.com wrote:

> Apologies my DLL's couldn't add weight to your argument,

Thanks for trying and it's no big deal anyway. Whether bots cheat has
become an ancient and lesser issue. I shifted my argument to equity
calculations, cube decisions, etc. being biased and inaccurate, which
makes them not quite so unbeatable, while waiting for better bots...

> there's a sadistic part of me that would bloody love to catch
> XG with it's grubby little fingers in the cash register :-)

In a sense, they were already caught stealing but were let off the hook
too easily and made however an amount of money from it. Related to
that, I had predicted that there would never be another updated version
of XG-3, which is holding true after close to 8 years by now. Perhaps the
reasons can be speculated on for fun in a different thread if people are
interested. ;)

MK

[Nasti Chestikov]

On Friday, 4 December 2020 at 06:16:51 UTC, MK wrote:

> Thanks for trying and it's no big deal anyway. Whether bots cheat has
> become an ancient and lesser issue. I shifted my argument to equity
> calculations, cube decisions, etc. being biased and inaccurate, which
> makes them not quite so unbeatable, while waiting for better bots...

Oh, you mean like GNUDung repeatedly not landing an 11-in-36 shot and then going all crybaby and wailing about being "very unlucky".

I'd like to take GNUDung's fanboys out into a supermarket parking lot and punch every single one of them in the face.

[Glen Arnold]

On Saturday, October 31, 2020 at 7:01:48 PM UTC-5, 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
If you manually roll dice and manually enter into (edit) every roll of the game...will this show if xgammon....an or snowy and or gnu and or jelly fish cheats....if outcome is same as when set on auto...Would this not show if computer program cheats or not??? G A

[Ahmet Ecevit]

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,

[MK]

Your comment/question quoting my entire first post
in a long discussion doesn't add anything specific to
it and is too general about topics that were rehashed
countless times, for me to get into again. Sorry... :(

MK

[MK]

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

[Ahmet Ecevit]

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

[MK]

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

[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

[snj5j5sn]

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 .

[Frank Berger]

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.

[MK]

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