Simple code and ideas to automate manual dice for XG or Gnubg

[MK]

In a different thread I had written:

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

"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.
".....
"I may be willing to tackle it myself.

I don't have time to create something fancy but below
is a sample code, as simple as it can be, to ask for a
seed, wait for player to press a key each time XG dice
dialog appears, roll dice, then show and pass it to XG.

It checks if user presses a key when no dice dialog is
displayed, in order to prevent an error loop. Additional
checks may be added to prevent user from interacting
with the dialog box at the same time, etc.

Alternatively, at the expense of background CPU cycles,
it can be modified to wait for dice dialogs by constantly
checking and supplying the dice rolls automatically with
no user interaction needed. A benefit of this will be that
the user won't have time to interact with the dialog box
and thus breaking the sequence of random dice rolled.

Of course, it can be given its own pretty window instead
of using the default console.

It will work the same way for Gnubg by simply changing
the dice dialog window name and sending the codes that
clicking on dice combination icons generate (which is not
obvious to me and would be nice if a Gnubg programmer
posts it here).

With the essentials that I provided, the rest is a matter
of making it look nicer and more user friendly. I'm sure
there are programmers here who would enjoy spending
a little time for a fun project that will be quite a usuful
tool for others as well.

MK

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

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

int seed, die1, die2;
byte keyp;
HWND xgdd;

int main() {

printf ("Enter seed: ");
scanf ("%d", &seed);
srand (seed);

while (seed > 0) {

system("pause");

xgdd = FindWindow (NULL, "Dice");

if (xgdd == 0) {
printf ("Wait for dice dialog\n");
}

else {
die1 = rand() % 6 + 1;
die2 = rand() % 6 + 1;
printf ("Rolled: %d %d \n", die1, die2);

SetForegroundWindow (xgdd);

keyp = die1 + 48;
keybd_event (keyp, 0, 0, 0);
keybd_event (keyp, 0, KEYEVENTF_KEYUP, 0);

sleep(1);

keyp = die2 + 48;
keybd_event (keyp, 0, 0, 0);
keybd_event (keyp, 0, KEYEVENTF_KEYUP, 0);
}
}
exit(0);
}

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

Tiny-C have problems with windows API but Digital
Mars or others should compile the above code fine.

[MK]

On August 25, 2022 at 10:13:06 PM UTC-6, MK wrote:

> Alternatively, at the expense of background CPU cycles,
> it can be modified to wait for dice dialogs by constantly
> checking and supplying the dice rolls automatically with
> no user interaction needed. A benefit of this will be that
> the user won't have time to interact with the dialog box
> and thus breaking the sequence of random dice rolled.

After playing a few games with the code I posted above,
I found it cumbersome to keep clicking on the console
window and pressing a key for each roll. So I followed my
own idea and modified it to feed the rolls autimatically.

You can download the executable "mkdice.bin" (named so
because of server restriction) and rename it "mkdice.exe".

https://montanaonline.net/backgammon/mkdice.bin

Or you can compile the below even simpler code yourself
using a portable C/C++ compiler like Digital Mars (< 4Mb
download, < 11Mb expanded) from this link:

http://ftp.digitalmars.com/Digital_Mars_C++/Patch/dm857c.zip

> Of course, it can be given its own pretty window instead
> of using the default console.

Actually, since the user interaction is so minimal, I find the
default console interface more than good emough.

> It will work the same way for Gnubg by simply changing
> the dice dialog window name and sending the codes that
> clicking on dice combination icons generate (which is not
> obvious to me and would be nice if a Gnubg programmer
> posts it here).

As usual, I'm disappointed but not surprised that nobody
responded to this paragraph.

Early versions of Gnubg accepted keyboard input also but
it was later botched botoxed to work only by mouse clicks
on dice combination icons, requiring users to visually locate
1 of 36 icons instead of 1 of 6 twice or simply press 2 keys.
I gues this can be called "painting the lily shit color"... :(

Anyway, here is the modified, simpler code. The additional
CPU usage is negligible in our age of heavy multi-tasking.

For what it accomplishes, I find the minimality and simplicity
of the code rather beautiful. Don''t you think?

MK

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

int seed, die1, die2;
byte keyp;
HWND xgdd;

int main() {

printf ("Enter seed: ");
scanf ("%d", &seed);
srand (seed);

while (seed > 0) {

while ((xgdd = FindWindow (NULL, "Dice")) == 0) {
sleep(1);

}

die1 = rand() % 6 + 1;
die2 = rand() % 6 + 1;

SetForegroundWindow (xgdd);

keyp = die1 + 48;
keybd_event (keyp, 0, 0, 0);
keybd_event (keyp, 0, KEYEVENTF_KEYUP, 0);

keyp = die2 + 48;
keybd_event (keyp, 0, 0, 0);
keybd_event (keyp, 0, KEYEVENTF_KEYUP, 0);

printf ("Rolled: %d %d \n", die1, die2);

sleep(5);
}

exit(0);
}
=======================================

[Axel Reichert]

MK <mu...@compuplus.net> writes:

> On August 25, 2022 at 10:13:06 PM UTC-6, MK wrote:
>
>> It will work the same way for Gnubg by simply changing
>> the dice dialog window name and sending the codes that
>> clicking on dice combination icons generate (which is not
>> obvious to me and would be nice if a Gnubg programmer
>> posts it here).
>
> As usual, I'm disappointed but not surprised that nobody
> responded to this paragraph.

GNU Backgammon can read dice from a file. Simple, portable (since you
can re-use your carefully created list for other "cheating" bots) and
totally sufficient. I am not disappointed that volunteer developers do
not spend more time on issues they (and me!) consider ridiculous, see
their classic dice complaint form, hilarious fun every time I reread it.
:-D

> Early versions of Gnubg accepted keyboard input

GNU Backgammon, when set to manual dice and run with "gnubg -t" accepts
dice entered as "31" and moves as "8 5 6 5". RTFM.

> here is the modified, simpler code

[...]

> die1 = rand() % 6 + 1;
> die2 = rand() % 6 + 1;

If I remeber correctly, C's standard library's pseudo-random number
generator (LCG) is considerably worse than GNU Backgammon's default
Mersenne Twister. The details would be too much maths. But, Murat, yes,
GNU Backgammon in a sense will then be playing with "loaded" dice! But
YOU brought them the board. (-:

Axel

[Nasti Chestikov]

On Tuesday, 30 August 2022 at 07:18:13 UTC+1, Axel Reichert wrote:

> GNU Backgammon can read dice from a file. Simple, portable (since you
> can re-use your carefully created list for other "cheating" bots) and
> totally sufficient.
>

> Axel

The problem I have with GnuDung and reading from a file is this (and you can prove this yourself): create a suitable file and then delete it after one roll........you'll find GnuDung continues to roll the numbers that were in the file........ergo, it's caching the rolls so that it can look at upcoming dice and play accordingly.

[Axel Reichert]

Nasti Chestikov <nasti.c...@gmail.com> writes:

> The problem I have with GnuDung and reading from a file is this (and
> you can prove this yourself): create a suitable file and then delete
> it after one roll........you'll find GnuDung continues to roll the
> numbers that were in the file........ergo, it's caching the rolls so
> that it can look at upcoming dice and play accordingly.

The problem I have with thinking like this (and you can prove this
yourself): read dice.c (GNU Backgammon is open source) and you will find
that exactly two dice are read from that file per call:

case RNG_FILE:

anDice[0] = ReadDiceFile(rngctx);
anDice[1] = ReadDiceFile(rngctx);
rngctx->c += 2;

Can you be please point to the line in which the look at upcoming dice
occurs? No? Learn to play better. And learn to code. Both are highly
rewarding activities.

Axel

[MK]

On August 30, 2022 at 12:18:13 AM UTC-6, Axel Reichert wrote:

> MK <mu...@compuplus.net> writes:

>> On August 25, 2022 at 10:13:06 PM UTC-6, MK wrote:

>>> It will work the same way for Gnubg by simply changing
>>> the dice dialog window name and sending the codes that
>>> clicking on dice combination icons generate (which is not
>>> obvious to me and would be nice if a Gnubg programmer
>>> posts it here).

>> As usual, I'm disappointed but not surprised that nobody
>> responded to this paragraph.

> GNU Backgammon can read dice from a file. .....

What does reading from file has to do with the discussion
about simulating manual dice by an automated process..?

> I am not disappointed that volunteer developers do not spend
> more time on issues they (and me!) consider ridiculous,

There is nothing "ridicoulous" in asking for documentation.

> see their classic dice complaint form, hilarious fun every time
> I reread it.
> :-D

What has such assholic shit to do with this discussion..?

>> Early versions of Gnubg accepted keyboard input

> GNU Backgammon, when set to manual dice and run with
> "gnubg -t" accepts dice entered as "31"

What has running Gnubg in CLI mode to do with my asking
about how to pass dice rolls to Gnubg in GUI mode..?

> and moves as "8 5 6 5". RTFM.

I read the fucking manual and it's not in there. WTF now..?

>> here is the modified, simpler code
> [...]
>> die1 = rand() % 6 + 1;
>> die2 = rand() % 6 + 1;

> If I remeber correctly, C's standard library's pseudo-random
> number generator (LCG) is considerably worse than GNU
> Backgammon's default Mersenne Twister.

It's good enough for my purposes but the sample code that
I offered can be modified to use whatever else RNG.

> The details would be too much maths.

Not really. There are many variants and versions of numerous
RNG source code out there, (some of which have been posted
here). No need to reinvent the wheel. It's a simple copy/paste.

> But, Murat, yes, GNU Backgammon in a sense will then be
> playing with "loaded" dice!

Not so. When an independent process (perhaps one that you
developed yourself) simulates manual dice by passing rolls
to Gnubg, it will be playing with dice less loaded than loaded
physical dice.

> But YOU brought them the board. (-:

Huh?

MK

[MK]

On August 30, 2022 at 11:32:01 AM UTC-6, Axel Reichert wrote:

> Nasti Chestikov <nasti.c...@gmail.com> writes:

>> The problem I have with GnuDung and reading from
>> a file is this (and you can prove this yourself): create
>> a suitable file and then delete it after one roll........
>> you'll find GnuDung continues to roll the numbers
>> that were in the file

> The problem I have with thinking like this (and you can
> prove this yourself): read dice.c

No, no, no! This is not how proper debating works.

First, you have to follow his instruction for you to
prove to yourself what he said he observed.

Did you do what he suggested? Did you observe
the same Gnubg behavior?

After doing that first, you need to offer your own
explanation for how and why Gnubg does that.

And then you can take your turn to tell him what
he can prove to himfelf and how...

> (GNU Backgammon is open source) and you will find
> that exactly two dice are read from that file per call:

You can't assert this. I'll explain why but let's first
clarify that Nasti has been talking about the Gnubg
EXE that he downloaded and he did several times
made the reasonable argument that the it may not
be compiled from the same published source code.

> anDice[0] = ReadDiceFile(rngctx);
> anDice[1] = ReadDiceFile(rngctx);
> rngctx->c += 2;

A few lines of code prove nothing whatsoever. One
needs to be capable of looking at the entire set of
source files, understanding the language that they
were coded in, going through the entire logic to see
if there may be anything visibly suspicious in there.

After having the mastery of the code, one also needs
to compile it himself to see what it actually does and
not just rely on a downloaded EXE.

Unless you can yourself claim that you are capable
of doing this, you have no right to ask others to do.

> Can you be please point to the line in which the look
> at upcoming dice occurs?

This is such stupid argument. :( I can ask you several
questions regarding just those lines alone that you
won't be able to answer but let me ask only one, which
is related to what started the thread:

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

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

That discussion was about XG's making multiple (also
apparently multi-threaded) calls per roll (or "per turn")
to the external dice DLL that I had created for testing.

Since then, I asked several times if any hot-shit-shot
bot programmer can offer a reasonable explanation
for why a bot would do such unexplainable, suspicious
things but nobody answered as of yet...

I don't think you can either. So, let me ask you an easier
one: Just by looking at those lines you shared above,
can you tell how many times they are executed per dice
roll (or "per turn")?

No? Then eat crow and swallow your own advice...

> No? Learn to play better. And learn to code. Both are
> highly rewarding activities.

I fail to see a connection between "playing" and "coding"
but what is even more impotant to lean is to "analyse"!

Coding is for peons. It's mechanical, easy. It's the analyst
who designs the software and hands a flowchart with the
specs to the peon and says: "Here code this". Actually,
being able to "read" someone else's code is harder to learn
than to "write" your own code... Okay, class dismissed. :)

MK

[Simon Woodhead]

On 31/08/2022 12:47 pm, MK wrote:

> A few lines of code prove nothing whatsoever. One
> needs to be capable of looking at the entire set of
> source files, understanding the language that they
> were coded in, going through the entire logic to see
> if there may be anything visibly suspicious in there.
>
> After having the mastery of the code, one also needs
> to compile it himself to see what it actually does and
> not just rely on a downloaded EXE.
>
> Unless you can yourself claim that you are capable
> of doing this, you have no right to ask others to do.

No more excuses, Murat. Thanks to Jon Kinsey for making
Windows builds much easier, posted to the bug-gnubg list:

> I setup some super-easy steps to build gnubg from source on Windows:
>
> 1. Download and install the latest version of MSYS2 from https://www.msys2.org/ e.g.
> msys2-x86_64-20210725.exe
> 2. Run the batch file from here: https://drive.google.com/file/d/1-52afhxiZGv2Nzt9AhFFTw_WrdNIemjZ/view?usp=sharing
> This will take about 10 minutes
>
> This builds gnubg to C:\msys64\mingw32\bin\gnubg.exe. I realise this builds the full GUI version, you will need to pass a flag to configure to build the command line version, at a guess ./configure --disable-gtk
> Jon

Now go and master the code and tell us where gnubg
is cheating. I'm sure we can all wait.

[Axel Reichert]

MK <mu...@compuplus.net> writes:

> No, no, no! This is not how proper debating works.

Tell me more.

https://www.fallacyfiles.org/introtof.html

anyone? (-;

> First, you have to follow his instruction for you to prove to yourself
> what he said he observed.

No. The observation is consistent with my quick glance at the source.

> After doing that first, you need to offer your own explanation for how
> and why Gnubg does that.

No. It is not me having a problem. The burden of proof is not on me.

[two dice are read from that file per call]

> You can't assert this.

Strictly speaking, you are right. I was using a sloppy formulation. The
file is read completely into an array, from which two values are passed
on to the engine. This explains the behaviour after deleting the
file. But the onus is not on me.

> let's first clarify that Nasti has been talking about the Gnubg EXE
> that he downloaded and he did several times made the reasonable
> argument that the it may not be compiled from the same published
> source code.

Do not switch topics.

> Unless you can yourself claim that you are capable of doing this, you
> have no right to ask others to do.

The onus is not on me.

> let me ask only one, which is related to what started the thread:
>
> "Proof XG is cheating, err teaching, even when using external DLL?"
>
> https://groups.google.com/g/rec.games.backgammon/c/sxlOCjtvAIM/m/BGMIOuDqAQAJ
>
> That discussion was about XG's making multiple (also apparently
> multi-threaded) calls per roll (or "per turn") to the external dice
> DLL that I had created for testing.

Do not switch topics.

> Just by looking at those lines you shared above, can you tell how many
> times they are executed per dice roll (or "per turn")?

Strawman. I am giving hints to others regarding their self-imposed
homework. I am not doing their homework. The onus is not on me.

>> No? Learn to play better. And learn to code. Both are
>> highly rewarding activities.
>
> I fail to see a connection between "playing" and "coding"

Generally speaking (and beautifully captured in the dice complaint
form): Dice-focussed players typically believe themselves to be strong,
but they are typically weak. Of course it cannot be their fault, hence
the (open source!) program must be cheating. Learning to code might help
them find out. Learning to play might help them to become less
dice-focussed.

Axel

[Nasti Chestikov]

So when I delete the file that GnuDung is reading the rolls from and it continues to play those rolls I should just learn to play better?

I shouldn't question where GnuDung is pulling the rolls?

Come on man, you *have* to contribute more than that to the debate?

[Simon Woodhead]

On 1/09/2022 2:58 am, Nasti Chestikov wrote:

> So when I delete the file that GnuDung is reading the rolls from and
> it continues to play those rolls I should just learn to play better?
>
> I shouldn't question where GnuDung is pulling the rolls?

Axel already explained this:

"The file is read completely into an array, from which two values are
passed on to the engine. This explains the behaviour after deleting
the file."

This is standard practise. It makes no sense to open a file, read
a record then close the file and repeat for every record. The file
is opened and read and stored in memory where it stays. Certainly,
the code *could* look further into the file if it wanted to "cheat",
but if it did, it would be in the source you've just compiled, yes?
So go get it...

> Come on man, you *have* to contribute more than that to the debate?

You and your alter ego are not debating. You're whining about rigged
dice without being willing to make any attempt to actually do what
Axel asked, namely "Can you please point to the line in which the
look at upcoming dice occurs?".

You've been shown how to obtain and compile the source, so you can't
whine about executables or make any other excuses. Bite the bullet,
learn how to compile the source, devise experiments to prove your
theories, document everything, including highlighting the source code
that you think is doing the wrong thing, and present it to the folks
on the bug-gnubg list. If you're not willing to do that, you're just
tilting at windmills.

[Timothy Chow]

On 8/31/2022 7:34 PM, Simon Woodhead wrote:
> You and your alter ego are not debating. You're whining about rigged
> dice without being willing to make any attempt to actually do what
> Axel asked, namely "Can you please point to the line in which the
> look at upcoming dice occurs?".

I'm waiting for Murat/Nasti to claim that all the compilers out there
are rigged. The compiler checks to see if what it's compiling is the
source code for GNU Backgammon, and if it is, then it inserts cheating
code into the object file, even when the source code looks clean.

The compiler, of course, also checks to see if it's being asked to
compile its own source code, and if so, it inserts the rigged object
code, so that the source code for the compiler also looks clean.

It's such an obvious explanation that I'm surprised Murat/Nasti has
not yet suggested it.

---
Tim Chow

[Axel Reichert]

Timothy Chow <tchow...@yahoo.com> writes:

> The compiler, of course, also checks to see if it's being asked to
> compile its own source code, and if so, it inserts the rigged object
> code, so that the source code for the compiler also looks clean.

You made my day! (-:

The key question is now only where the rigged object code is hidden. My
suspicion is that it is in the dice file that Nasti created: It is read
by the compiler, and its content will still be present in memory even
after that file is deleted. Then the compiler can easily look ahead at its
upcoming compilation tasks and fool the poor user appropriately. (-;

Best regards

Axel

[Axel Reichert]

Timothy Chow <tchow...@yahoo.com> writes:

> The compiler, of course, also checks to see if it's being asked to
> compile its own source code, and if so, it inserts the rigged object
> code, so that the source code for the compiler also looks clean.

[MK]

On August 30, 2022 at 10:02:43 PM UTC-6, Simon Woodhead wrote:

> On 31/08/2022 12:47 pm, MK wrote:

>> A few lines of code prove nothing whatsoever. One
>> needs to be capable of looking at the entire set of
>> source files, understanding the language that they
>> were coded in, going through the entire logic to see
>> if there may be anything visibly suspicious in there.

>> After having the mastery of the code, one also needs
>> to compile it himself to see what it actually does and
>> not just rely on a downloaded EXE.

>> Unless you can yourself claim that you are capable
>> of doing this, you have no right to ask others to do.

> No more excuses, Murat. Thanks to Jon Kinsey for
> making Windows builds much easier, posted to the
> bug-gnubg list:

> .....

> Now go and master the code and tell us where gnubg
> is cheating. I'm sure we can all wait.

I'm going to take the time and make the effort to explain
it in way that even a Woodhead can understans and then
I'll expect that you will change your attitude towards me.

I'll do this in three sections: past, present and future.

A) Past: When I first said anything about bots cheating,
it wasn't because I was losing to them. To the opposite,
I was winning and I deeply resented all those resident,
(mostly mathematicians), assholes who assumed that
only losers would accuse bots of cheating, with some
of them going as far to create "bot complaint forms", etc.

I felt challenged to stay and put up a fight against them.
25+ years later, I have been gaining ground for the past
few years, even if very slowly but securely, inch by inch.

Since I was not a "gamblegammon giant", who had never
even played with a cube before, one possible explanation
for my success against bots could be that the bots were
cheating and I was able to detect, predict, preempt and
exploit the cheating of the bots.

This explanation was actually being much more humble
than anyone else here, about offering a reason for one's
success, which in my case was unexpected, i.e. against
the pompous assholes' ass-sumptions.

B) Present: Over those 25+ years, as I played literally tens
of thousands of games against various bots, in numerous
types of experiments (that I openly shared along the way),
I started to realize that I was perhaps really better than the
bots and gradually grew truely confident that I could beat
the bots on demand, consistently. With that, whether the
bots cheated or not eventually became irrelevant.

However, because the "step-by-steps instructions to prove
that bots didn't cheat" offered by some half-brained idiots
kept being amusing, I also kept playing the devil's advocate
to defeat them just as a brain exercise.

Currently, I have no interest in spending time and effort to
prove that any bot cheats by looking at source codes but
let me toy with for the fun of it anyway.

1- You are obviously not intelligent enough to understand
that any comments about Gnubg's cheating were made
based on the downloadable EXE files. There is no way to
know or prove that those EXE files were compile from the
same source files you are daring me look at and compile.
Make an effort to understand this.

2- Do you yourself have the mastery of the code that you
are throwing at me? If I say that I looked at it and show
you some sections of it as evidence of Gnubg's cheating,
will you be able to tell if I'm just bluffing or not?

3- Suppose I look at the code and I don't find any evidence
of Gnubg's cheating. Would my falling short of finding any
evidence of it be enough of a proof that it's not there (i.e.
that Gnubg doesn't cheat)? Do you realize that, in a way,
you are daring me to prove a negative?

4- Etc. Etc. Enough on this...

C) Future: After realizing that I may actually be better than
the bots, I moved on the exploring how and why. Eventually
I concluded that it was rather the bots that were worse than
me, becaue of the flaws in how they calculated equities,
cube points, match tables, error rates, etc. "bullshit"!

My experiments had already shown that (whether I could
win more than 50% against the bots in every type/variant
of experiment), I could consistently win more than what
would be expected from me based on my checker and/or
error rates.

This is obviously a clear proof that the bots' interrelated
calculations of equities, cube points, match tables, error
rates, etc. are all wrong, inaccurate of an unknown scale.

Axel's various experiments have also repeatedly proven
this. If you have noticed, I have been hammering on this
the most recently and I will continue to do so until some
among you will hopefully seek treatment and come out
of your self-deception and your denials of the realities.

Also in the future, I would like to develop an ultimately
user configurable bot (which I had called a "Legobot"),
to allow people to experiment with all kinds of "what if"
combinations, in order prove to themselves that the
so-called "cube skill theory", etc. are total bullshits.

It would be nice to not have to reinvent the wheel and
use code from an open source bot like Gnubg. I just
looked at Gnubg's source code folder to see it has 600
or so files in it. It's just too bloated a pile of garbage to
make use of. It's hard to believe that some people had
gone as far to add a "Dice manipulation" feature to it.

I wish I hadn't predicted 20+ years ago that Jellyfish
source code would never become pupblic no matter
how obsolete it became. It would have been nice to
have it now. Or maybe one of the very early versions
of Gnubg? Or even better, maybe someone like you
would eliminate all the garbage from Gnubg, i.e. only
leave what's needed for a plain "player" version, with
none of the "painted brown lily shit" of CLI, rollouts,
analysis, scripting, etc. so that I can make a reasonable
effort to build a new bot based on it (but not to peddle
it, of course, for $50 as YG+++ or ZG++++).

This is all from me for now. It's your turn, if you want.

MK

[Axel Reichert]

MK <mu...@compuplus.net> writes:

> This is obviously a clear proof that the bots' interrelated
> calculations of equities, cube points, match tables, error rates,
> etc. are all wrong, inaccurate of an unknown scale.
>
> Axel's various experiments have also repeatedly proven this.

Not at all. I have shown other things (or not, depending on which post
of you one pulls in as a "reference"), but certainly not what you claim
above. I object to being mentioned as a "witness"/supporter in the
context of your (mostly futile) windmill fighting.

Axel

[Simon Woodhead]

On 1/09/2022 10:25 pm, MK wrote:

> I'm going to take the time and make the effort to explain
> it in way that even a Woodhead can understans and then
> I'll expect that you will change your attitude towards me.

"even a Woodhead can understand"?? You start your sermon
with an insult? My Wooden head is as tough as old oak ;-)

> I'll do this in three sections: past, present and future.

Irrelevant rubbish.

> Currently, I have no interest in spending time and effort to
> prove that any bot cheats by looking at source codes but
> let me toy with for the fun of it anyway.

But you expect others to spend time and effort to prove
otherwise. You are the accuser, you have to provide the
body of evidence for your claims.

> 1- You are obviously not intelligent enough to understand
> that any comments about Gnubg's cheating were made
> based on the downloadable EXE files. There is no way to
> know or prove that those EXE files were compile from the
> same source files you are daring me look at and compile.
> Make an effort to understand this.

Correct, and you now have the means to prove this for
yourself, yet you "have no interest". And another insult.
Does it make you feel better to insult the people trying to
help you? You can get treatment for that.

> 2- Do you yourself have the mastery of the code that you
> are throwing at me? If I say that I looked at it and show
> you some sections of it as evidence of Gnubg's cheating,
> will you be able to tell if I'm just bluffing or not?

Yes if you provide appropriate context.

> 3- Suppose I look at the code and I don't find any evidence
> of Gnubg's cheating. Would my falling short of finding any
> evidence of it be enough of a proof that it's not there (i.e.
> that Gnubg doesn't cheat)? Do you realize that, in a way,
> you are daring me to prove a negative?

No, I'm daring you to prove anything at all in the time
honoured way of proposing a theory, constructing an
experiment to prove it (or not), then running that
experiment and publishing the results. You will predictably
claim that you've already done this with your "hundreds of
matches against gnubg" but you didn't scientifically document
what you were trying to prove.

> C) Future: After realizing that I may actually be better than
> the bots, I moved on the exploring how and why. Eventually
> I concluded that it was rather the bots that were worse than
> me, becaue of the flaws in how they calculated equities,
> cube points, match tables, error rates, etc. "bullshit"!

Which flaws are those? Finding these calculations in the
source should be quite easy for someone of your abilities.

> This is obviously a clear proof that the bots' interrelated
> calculations of equities, cube points, match tables, error
> rates, etc. are all wrong, inaccurate of an unknown scale.

But no-one agrees with you, so you're going to have to offer
a much more rigorous proof if you wish to gain any credibility.

> Axel's various experiments have also repeatedly proven
> this. If you have noticed, I have been hammering on this
> the most recently and I will continue to do so until some
> among you will hopefully seek treatment and come out
> of your self-deception and your denials of the realities.

Axel's experiments have done no such thing. Telling people
smarter than you that they "need treatment" is a childish
cop out. You are the one denying reality here.

> Also in the future, I would like to develop an ultimately
> user configurable bot (which I had called a "Legobot"),
> to allow people to experiment with all kinds of "what if"
> combinations, in order prove to themselves that the
> so-called "cube skill theory", etc. are total bullshits.

This would be wonderful. Instead of spending so much time
insulting people who disagree with your theories, you could
have been building LegoBot to prove that you have something
of substance. The reality is you will never develop such a
bot because you're not willing to learn the skills required.
Instead, you seem to think that insulting people who can
help you is some kind of motivation for them. It isn't.
Axel's patience with you is that of a saint, yet you still
insult him at every opportunity. It's clear who needs
treatment here.

> It would be nice to not have to reinvent the wheel and
> use code from an open source bot like Gnubg. I just
> looked at Gnubg's source code folder to see it has 600
> or so files in it. It's just too bloated a pile of garbage to
> make use of. It's hard to believe that some people had
> gone as far to add a "Dice manipulation" feature to it.

Feel free to rewrite gnubg as you wish. You are welcome to
use the free, public, gnubg source as your base. Rip out
everything you don't like and start with the basics so
you can build your bot. People who develop code don't like
reinventing wheels either. That's why we have libraries.
Lots of libraries, full of code, that do all the stuff we don't
want to reinvent. But you know that, right? Your own few lines
of code made a call to a library function called "rand". Can
you be sure "rand" is providing you with random numbers?

> I wish I hadn't predicted 20+ years ago that Jellyfish
> source code would never become pupblic no matter
> how obsolete it became. It would have been nice to
> have it now.

Why? You wouldn't have a clue what to do with it. If you're
not willing to look at the gnubg code, why would you look
at the jellyfish code?

You're like a fish out of water, Murat. Always squirming around,
gasping for air. You've been led back to the water, but no-one
can make you take the plunge. You have to do that yourself. No,
it's not easy but come on, you're always telling us how smart
you are. Prove it for once.

[Timothy Chow]

On 9/1/2022 5:48 PM, Simon Woodhead wrote:
> Correct, and you now have the means to prove this for
> yourself, yet you "have no interest". And another insult.
> Does it make you feel better to insult the people trying to
> help you? You can get treatment for that.

Why would he get treatment when his current behavior makes him
feel good?

Berating Murat isn't going to change his behavior. Arguably,
the best thing to do, if one were concerned about his mental
health, would be to ignore him. Lacking feedback, he might
eventually give up and find other outlets for his energy.
Giving him grist for his mill just causes him to sink more
time into USENET and spiral further down.

But, to be honest, I don't care about Murat's mental health.
I prefer to exploit him for entertainment. It's a lot more
fun that way!

---
Tim Chow

[Simon Woodhead]

You are correct of course, trolls shouldn't be fed.
But the entertainment factor is irresistible sometimes.

[MK]

On September 1, 2022 at 8:09:07 AM UTC-6, Axel Reichert wrote:

> MK <mu...@compuplus.net> writes:

>> This is obviously a clear proof that the bots' interrelated
>> calculations of equities, cube points, match tables, error
>> rates, etc. are all wrong, inaccurate of an unknown scale.

>> Axel's various experiments have also repeatedly proven this.

> Not at all. I have shown other things (or not, depending
> on which post of you one pulls in as a "reference"), but
> certainly not what you claim above.

Yes, you did but you may have not realized that you did
because you didn't do it intentionally.

Take the example that your mutant bot making random
cube decisions winning 15%. Based on let's say Snowie's
1 ER = 33 ELO, I find that extremely high than expected.

What effectively nullifies the findings of you experiments
is that you delete your data :( which even a junior analyst,
scientist, mathematician would never do.

I can understand if you are unwilling the compare actual
vs expected results, etc. just keep your game files and we
will be glad to analyse them and do comparisons. Either
make your experiment data set public or at least use your
math skills to convert ER/PR/ELO to expected winnings
or don't waste your nor our time with stuff of no use.

> I object to being mentioned as a "witness"/supporter
> in the context of your (mostly futile) windmill fighting.

I don't need your consent to use what you publish as the
findings of your experiments in supporting my arguments.

I argue that random cube play, i.e. zero cube skill, winning
15% is so high to prove that any bot calculations related
to it such as equities, cube points, match tables, error rates,
etc. are all inaccurate bullshit.

If you don't have the math skills needed to extrapolate, you
can let any strong bot to analyse your game files and do the
calculations for you...

MK

[MK]

On September 1, 2022 at 3:48:41 PM UTC-6, Simon Woodhead wrote:

> On 1/09/2022 10:25 pm, MK wrote:

>> I'm going to take the time and make the effort to explain
>> it in way that even a Woodhead can understans and then

> "even a Woodhead can understand"?? You start your
> sermon with an insult?

Sorry, I couldn't help it. The temptation was just too great. :(

> My Wooden head is as tough as old oak ;-)

I wouldn't doubt it but don't go around butting heads with
other woodheads who may have heads harde than oak. ;)

>> I'll do this in three sections: past, present and future.

> Irrelevant rubbish.

It's very relevant. Nothing stays the same over time. I'm not
the same person as 25 years ago when I first posted here.

>> Currently, I have no interest in spending time and effort
>> to prove that any bot cheats by looking at source codes
>> but let me toy with for the fun of it anyway.

> But you expect others to spend time and effort to prove
> otherwise. You are the accuser, you have to provide the
> body of evidence for your claims.

I wasn't asking anyonw to prove anything. I just corrected
Axel for doing what you are accusing me of doing... :)

Also, over time, my arguments evolved from "bots cheating
humans" to "humans being cheated by bots"!

If you can't see the difference, ask Chow. He understood it
many years ago and translated it to others' languages...

>> 1- You are obviously not intelligent enough to understand
>> that any comments about Gnubg's cheating were made
>> based on the downloadable EXE files. There is no way to
>> know or prove that those EXE files were compile from the
>> same source files you are daring me look at and compile.
>> Make an effort to understand this.

> Correct, and you now have the means to prove this for
> yourself, yet you "have no interest". And another insult.

I always had the means but it was never worth my time and
whether bots cheat became even more irrelevant as I just
said. Why do you keep insisting on this instead of moving on?

It's good to see that my encouragement that you call insult
seems to have helped you to finally understant...

>> 2- Do you yourself have the mastery of the code that you
>> are throwing at me? If I say that I looked at it and show
>> you some sections of it as evidence of Gnubg's cheating,
>> will you be able to tell if I'm just bluffing or not?

> Yes if you provide appropriate context.

Then, why didn't come forward to correct Axel about what
he said the code was doing? It's not too late if you want to
do it before I respond to his post next. ;)

>> C) Future: After realizing that I may actually be better than
>> the bots, I moved on the exploring how and why. Eventually
>> I concluded that it was rather the bots that were worse than
>> me, becaue of the flaws in how they calculated equities,
>> cube points, match tables, error rates, etc. "bullshit"!

> Which flaws are those? Finding these calculations in the
> source should be quite easy for someone of your abilities.

No need to look at the code for this. The bot/s aready use
some of those numbers as input from files that you can see
and print out others of those numbers that they calculate by
analysing game records. If you can come out of your denial
and look, they are all visible in broad daylight.

>> This is obviously a clear proof that the bots' interrelated
>> calculations of equities, cube points, match tables, error
>> rates, etc. are all wrong, inaccurate of an unknown scale.

> But no-one agrees with you, so you're going to have to offer
> a much more rigorous proof if you wish to gain any credibility.

There is a limit to what I can do to actually help you. I consider
that I sow may seeds and live on...

> Axel's experiments have done no such thing.

See my response to him on this. Maybe you can do better than
him at making more out of his finding that "zero cube skill" can
win 15%...??

> Your own few lines of code made a call to a library function
> called "rand". Can you be sure "rand" is providing you with
> random numbers?

I already said it was good enough for my purposes. It hasn't
been a concern for me but since you are raising the question,
I will separately post a better code after posting this.

>> I wish I hadn't predicted 20+ years ago that Jellyfish
>> source code would never become pupblic no matter
>> how obsolete it became. It would have been nice to
>> have it now.

> Why? You wouldn't have a clue what to do with it. If you're
> not willing to look at the gnubg code, why would you look
> at the jellyfish code?

Stop making disconnected, stupid arguments. It's perfectly
okay for someone to want to look at some code and not at
some other, for whatever reasons he may have.

The reason I had made that prediction at the was that JF
was caught cheating and disappeared fron the scene soon
after. For one thing, looking at JF code could satisfy that
curiousity...

A better reason would be that JF player was very compact
for having all the desirable features in a "player version" of
a bg bot.

MK

[MK]

On September 1, 2022 at 3:48:41 PM UTC-6, Simon Woodhead wrote:

> On 1/09/2022 10:25 pm, MK wrote:

> Your own few lines of code made a call to a library
> function called "rand". Can you be sure "rand" is
> providing you with random numbers?

Since we are talking about fetching dice rolls from
files, here is a modified version of my simple sample
code to read dice rolls from a file and to pass them
automatically to XG, for the ones who don't find the
rand() function random enough and who may trust
better files from random.org, Bgblits web site, etc.

You're all welcome. ;)

MK

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

int die1, die2, dise;
FILE *dicef;

byte keyp;
HWND xgdd;

int main() {

dicef = fopen("dicefile.txt", "r");

if (dicef == NULL) {
printf ("Can't open dice file\n");
getch ();
exit(0);
}

while (1) {

while ((xgdd = FindWindow (NULL, "Dice")) == 0) {
sleep (1);
}

if (feof (dicef)) {
rewind (dicef);
}

fscanf (dicef, "%u", &dise);

die1 = dise % 10;
die2 = dise / 10;

SetForegroundWindow (xgdd);

keyp = die1 + 48;
keybd_event (keyp, 0, 0, 0);
keybd_event (keyp, 0, KEYEVENTF_KEYUP, 0);

keyp = die2 + 48;
keybd_event (keyp, 0, 0, 0);
keybd_event (keyp, 0, KEYEVENTF_KEYUP, 0);

printf ("Rolled: %d %d \n", die1, die2);

sleep (1);
xgdd = 0;
}

exit (0);
}
==========================================

[MK]

On August 31, 2022 at 7:05:33 PM UTC-6, Tim Chow wrote:

> I'm waiting for Murat/Nasti to claim that all the

> compilers out there are rigged. ....

Go fuck yourself somewhere else away from my sight!

MK

[MK]

On September 1, 2022 at 7:10:09 PM UTC-6, Simon Woodhead wrote:

> You are correct of course, trolls shouldn't be fed.
> But the entertainment factor is irresistible sometimes.

And you go give him a "hand"...!

Pack of sick dogs. :(

MK

[MK]

On August 30, 2022 at 11:32:53 PM UTC-6, Axel Reichert wrote:

> MK <mu...@compuplus.net> writes:

>> First, you have to follow his instruction for you to
>> prove to yourself what he said he observed.

> No. The observation is consistent with my quick
> glance at the source.

Then you should have indicated that in your response
to him. You didn't because it wasn't obvious to you at
first but my slapping you helped you see it. ;)

>> After doing that first, you need to offer your own
>> explanation for how and why Gnubg does that.

> No. It is not me having a problem. The burden of
> proof is not on me.

He tried (whatever he was capable of) in order to make
you prove it to yourself but you totally ignored him and
you tried to prove the opposite to him. Why did you feel
a need to do that if it wasn't your problem..?

> [two dice are read from that file per call]

>> You can't assert this.

> Strictly speaking, you are right.

Strictly, loosely, east or west; I was right, period!

> I was using a sloppy formulation. The file is read
> completely into an array, from which two values
> are passed on to the engine.

You didn't know that before I asked how many time the
code was executed. You got the hint and you found out.

You should thank you for the "publi education" you are
receiving here... :)

> This explains the behaviour after deleting the file. But
> the onus is not on me.

Why then did you feel a need to respond to him with the
wrong answer, exposing your ignorance.

Even now you don't know what you are talking about.
Are you sure that "the file is read completely into an
array"..? Go find the answer and come back to let me
know.

>> let's first clarify that Nasti has been talking about the
>> Gnubg EXE that he downloaded and he did several
>> times made the reasonable argument that the it may
>> not be compiled from the same published source code.

> Do not switch topics.

I'm not. I'm just providing additional historical info for the
ones who may have never read the past discussions about
it or may be too senile to remember.

>> let me ask only one, which is related to what started the thread:
>> "Proof XG is cheating, err teaching, even when using external DLL?"

>> ttps://groups.google.com/g/rec.games.backgammon/c/sxlOCjtvAIM/m/BGMIOuDqAQAJ
>> That discussion was about XG's making multiple (also apparently
>> multi-threaded) calls per roll (or "per turn") to the external dice
>> DLL that I had created for testing.

> Do not switch topics.

Are you a joke..? :) Scroll up all the way the the first line of my
initial post in this thread and you will see my reference to the
thread, from which I spawned this one.

If you aren't capable of following/remembering even a short
thread of discussion, it's your shortcoming; don't accuse me
of switching the topic.

>> Just by looking at those lines you shared above, can you
>> tell how many times they are executed per dice roll (or
>> "per turn")?

> Strawman. I am giving hints to others regarding their
> self-imposed homework. I am not doing their homework.
> The onus is not on me.

Strawman? Hah, hah! :) Fuck that anus being on you shit.
That question was the slap that made you discover that
your snipped of code was executed not just once per turn,
but multiple times (i.e. to fill an array). You should thank
me for educating you. Why must you be so inrecognisant?

MK

[MK]

On August 31, 2022 at 5:35:04 PM UTC-6, Simon Woodhead wrote:

> On 1/09/2022 2:58 am, Nasti Chestikov wrote:

>> I shouldn't question where GnuDung is pulling the rolls?

> Axel already explained this:

No he didn't. Until I asked him how many times his snipped
of code was executed per turen, he didn't even know that
a number of dice rolls were read into memory. He cockily
asserted that his snipped of code produced to dice per roll
and abrasively asked Nasti to point out some shit it there.

> "The file is read completely into an array, from which...

> This is standard practise.

It's not!

> It makes no sense to open a file, read a record then close
> the file and repeat for every record.

The file isn't closed after every read. With the computing
speeds we have today, the difference of reading 10 bytes
1,000 times vs reading 10,000 bytes 1 time isn't even worth
talking about let alone considering in programming.

> Certainly, the code *could* look further into the file if it
> wanted to "cheat", but if it did, it would be in the source
> you've just compiled, yes? So go get it...

What if he can't get it, asshole!? He has every right to be
suspicious of an unexpected behaviour that he is able
to observe by the bot and raise a question about it. You
have answered that bots reads dice rolls into an array.
Leave it at that! Why do you have to ask him to prove
anything back?

Now that you clarified how Gnubg "reads ahead" dice
rolls, how about letting us benefit of your deep knowledge
in computing to explain to us why on earth a bg bot would
make multiple/multi-threaded calls per roll (or before cube
actions between rolls) to the external DLL..!? Go ahead, we
are listening.

> Axel asked, namely "Can you please point to the line
> in which the look at upcoming dice occurs?"

Axel couldn't even point to his own dumb ass! What right
did he have to ask anyone else to point at anything else?

MK

[MK]

On September 1, 2022 at 2:43:56 AM UTC-6, Axel Reichert wrote:

> Timothy Chow <tchow...@yahoo.com> writes:

>> The compiler, of course, also checks to see if .....

> You made my day! (-:

I bet you appreciated him doing that after I ruined
your day for you... ;)

Arrogant, ignorant, mentally ill gamblegammon
assholes in denial of simple reality..! :(

Why don't you all stop sitting in a circle and jacking
off one another and answer some of my questions?

Like you, Axel, why don't you post the game files you
base your calculations/conclusions on, so that we
can double-check them and then go on to deriving our
own conclusions/arguments based on them?

I never would have thought you would be such a slick
coward to act like I'm not talking to you... :( Pyuke! :(

MK

[Timothy Chow]

Don't you want to watch?

---
Tim Chow

[Nasti Chestikov]

On Thursday, 1 September 2022 at 22:48:41 UTC+1, Simon Woodhead wrote:

> Does it make you feel better to insult the people trying to
> help you? You can get treatment for that.

And then a couple of paragraphs later.....

> Telling people smarter than you that they "need treatment"
> is a childish cop out.

Glorious. But I concede that there was a lot of background noise to your post, I think "mom" is calling you for dinner.

Now run along little boy, make sure you eat up all your greens.

[Nasti Chestikov]

How's that Lamborghini you nearly totalled in Vegas? Insurance company torn you a new one yet?

[Simon Woodhead]

Apparently NC fails to recognise humour.
You can get help for that too :-)

[Timothy Chow]

No, I have to pay for it out of my own pocket with my profits from
Eraser.

---
Tim Chow

[MK]

On August 30, 2022 at 10:02:43 PM UTC-6, Simon Woodhead wrote:

> No more excuses, Murat. Thanks to Jon Kinsey for making
> Windows builds much easier, posted to the bug-gnubg list:

>> 1. Download and install the latest version of MSYS2 from
>> https://www.msys2.org/ e.g. msys2-x86_64-20210725.exe
>> 2. Run the batch file from here: https://drive.google.com/file
>> /d/1-52afhxiZGv2Nzt9AhFFTw_WrdNIemjZ/view?usp=sharing

>> .....

Thanks for daring and prodding me on this, "oakhead" ;)

And with thanks to Kinsey for his work, firstly here are
some technical info for everyone's benefit.

I tried it and it worked without a glitch, bot by getting the
source code from the web or from the local gnubg folder.
It also worked from a portable drive by just relocating the
two folders needed. Msys2 only creates a handful registry
entries, mostly for uninstalling. It takes quite a few minutes
to run. I haven't tried it yet but after the initial run, it may be
possible to execute only the final command to build gnubg.

Now back to my comments. After growing frustrated with
Axel's being unwilling to do better than half-ass experiments
or to share his data and code, I tried to run some of my own
using Gnubg's existing features, as a first step towards more
later but I ran into bugs or problems with the setups of my
two computers.

Along with reporting my problem on bug-gnubg list, I also
suggested a few easy features for Gnubg, specifically for
running all sorts of experiments. See thread:

https://lists.gnu.org/archive/html/bug-gnubg/2022-09/msg00003.html

Joseph Heled, (one of the original developers of Gnubg),
has shown interest bus has not yet committed to doing it.
The reason I would like to see one of them do it is that the
features would then become permanent part of Gnubg. I'll
give them some time to digest the idea, hoping for it.

For the first time, I overcame my dreading that it would be
very cryptic and looked at the eval.c code. To my surprise,
it seemed consistent and with quite a few comments. By
looking at the code, I was able to better visualize what to
propose and to describe in detail, along with examples of
how the features would be useful. For someone familiar
with the code, it should be a very quick and easy task.

It would take adding only a couple of dozen lines, (without
modifying any existing ones), adding a few settings to the
main user config file and modifying the gtk file for player
settings. If nobody helps with it, I think I'll try to tackle it
myself even though it will take me longer since C is not
my "mother tongue" but at least I won't have to understand
anything more about how everything else works in Gnubg.

BTW: If Gnubg was a native Windows software, I probably
would have done this long time ago but I've always had a
dislike for Unix, let alone using Unix emulators on Windows.
This will be a one time, minor exception. :)

MK

[Simon Woodhead]

On 21/09/2022 2:28 am, MK wrote:

> On August 30, 2022 at 10:02:43 PM UTC-6, Simon Woodhead wrote:
>
>> No more excuses, Murat. Thanks to Jon Kinsey for making
>> Windows builds much easier, posted to the bug-gnubg list:
>
>>> 1. Download and install the latest version of MSYS2 from
>>> https://www.msys2.org/ e.g. msys2-x86_64-20210725.exe
>>> 2. Run the batch file from here: https://drive.google.com/file
>>> /d/1-52afhxiZGv2Nzt9AhFFTw_WrdNIemjZ/view?usp=sharing
>>> .....
>
> Thanks for daring and prodding me on this, "oakhead" ;)

[...]

> For the first time, I overcame my dreading that it would be
> very cryptic and looked at the eval.c code. To my surprise,

That wasn't so hard after all, was it Murat?

> It would take adding only a couple of dozen lines, (without

So do it!

> BTW: If Gnubg was a native Windows software, I probably
> would have done this long time ago but I've always had a
> dislike for Unix, let alone using Unix emulators on Windows.
> This will be a one time, minor exception. :)

One of your most amusing statements ever :-)
If Windows was used to run/develop the internet, we'd still be
using teletypes...

[MK]

On September 20, 2022 at 5:42:52 PM UTC-6, Simon Woodhead wrote:

> On 21/09/2022 2:28 am, MK wrote:

>> It would take adding only a couple of dozen lines, (without

> So do it!

I already explained in great detail what my suggestions
and my intentions were, for the benefit of rgb in general.

I already thanked you for your stubborn prodding me but
you never said anything about your reasons for it. So I'm
asking you now:

1) Are you asking me to do it hoping that I will fail at it so
that will make you happy somehow?

2) Are you asking me to do it because you want it done so
that you can use it to experiment yourself in order to learn?

2a) If so, would it be just as good if someone else does it?

3) Most importantly, don't you have nothing to say about
the essence of the experiments that I'm suggesting? Do
you understand what they could reveal? Etc.? Please try
to give an elaborate answer that may be useful to us all,
instead of your pathetic, brainless one-liners... :(

It's my turn to dare you to find out what you are made of.

MK

[Simon Woodhead]

On 21/09/2022 4:40 pm, MK wrote:

> 1) Are you asking me to do it hoping that I will fail at it so
> that will make you happy somehow?

No.

> 2) Are you asking me to do it because you want it done so
> that you can use it to experiment yourself in order to learn?

No.

> 2a) If so, would it be just as good if someone else does it?

Don't care.

> 3) Most importantly, don't you have nothing to say about
> the essence of the experiments that I'm suggesting? Do

No.

> you understand what they could reveal? Etc.? Please try
> to give an elaborate answer that may be useful to us all,
> instead of your pathetic, brainless one-liners... :(

No.

> It's my turn to dare you to find out what you are made of.

Yawn.

[MK]

On September 21, 2022 at 12:46:59 AM UTC-6, Simon Woodhead wrote:

> On 21/09/2022 4:40 pm, MK wrote:

>> 1) Are you asking me to do it hoping that I will fail at it so
>> that will make you happy somehow?

> No.

Okay, then why?

>> 2) Are you asking me to do it because you want it done so
>> that you can use it to experiment yourself in order to learn?

> No.

Okay, then why?

I'll stop trying to gues logical reasons and will simply let you
tell me why are you doing what you are doing?

Surely not without any reason..?

>> 2a) If so, would it be just as good if someone else does it?

> Don't care.

Good enough. Depending on your above reason/s, it may not
matter.

>> 3) Most importantly, don't you have nothing to say about
>> the essence of the experiments that I'm suggesting? Do

> No.

Okay, fine. You sure have your right to be a brainless idiot.

>> you understand what they could reveal? Etc.? Please try
>> to give an elaborate answer that may be useful to us all,
>> instead of your pathetic, brainless one-liners... :(

> No.

Okay, fine. You sure have your right to be a brainless asshole.

>> It's my turn to dare you to find out what you are made of.

> Yawn.

Google the words: "psychological reasons for yawning". You
may discover something about yourself... ;)

MK

[Simon Woodhead]

On 26/09/2022 6:24 pm, MK wrote:

>>> 1) Are you asking me to do it hoping that I will fail at it so
>>> that will make you happy somehow?
>
>> No.
>
> Okay, then why?

Because I don't hope for people to fail. Besides, my encouraging
you to do your own investigating and experimenting instead of
demanding others do it for you, had a positive effect.

>>> 2) Are you asking me to do it because you want it done so
>>> that you can use it to experiment yourself in order to learn?
>
>> No.
>
> Okay, then why?

Because I am not interested in learning how to automate dice
feeds to bots.

> I'll stop trying to gues logical reasons and will simply let you
> tell me why are you doing what you are doing?

As I'm a brainless idiot, how would I know what I'm doing?

> Surely not without any reason..?

I try to have reasons for everything I waste time on.

>>> 2a) If so, would it be just as good if someone else does it?
>
>> Don't care.
>
> Good enough. Depending on your above reason/s, it may not
> matter.

It doesn't. And technically, my answer was wrong, it should have
been "Not Applicable" instead of "Don't care".

>>> 3) Most importantly, don't you have nothing to say about
>>> the essence of the experiments that I'm suggesting? Do
>
>> No.
>
> Okay, fine. You sure have your right to be a brainless idiot.

Because I disagree with your methods, I'm a brainless idiot.
Ok, thanks, got it.

>>> you understand what they could reveal? Etc.? Please try
>>> to give an elaborate answer that may be useful to us all,
>>> instead of your pathetic, brainless one-liners... :(
>
>> No.
>
> Okay, fine. You sure have your right to be a brainless asshole.

Because I'm not interested in your conspiracy theories, I'm a
brainless asshole. Ok, thanks, got it.

>>> It's my turn to dare you to find out what you are made of.
>
>> Yawn.
>
> Google the words: "psychological reasons for yawning". You
> may discover something about yourself... ;)

I already know plenty of things that are interesting about myself.

Was there a point to all this? It's clear you get a kick from
insulting people, so Google the words "psychological reasons for
insulting a person". You may discover something interesting about
yourself... ;)

[MK]

On September 27, 2022 at 12:00:23 AM UTC+2, Simon Woodhead wrote:

> On 26/09/2022 6:24 pm, MK wrote:

>>>> 1) Are you asking me to do it hoping that I will
>>>> fail at it so that will make you happy somehow?

>>> No.

>> Okay, then why?

> Because I don't hope for people to fail. Besides, my
> encouraging you to do your own investigating and
> experimenting instead of demanding others do it
> for you, had a positive effect.

You still refuse to see that I'm not asking anyone to do
anything "for me, for my benefit alone". I already have
done my own experiments and shared my findings here
but they failed to convince you indogtrained folks. Thus
I was doing my part of encouraging you all to do those
experiments yourselves in order to convince yourselves.

>>>> 2) Are you asking me to do it because you want it
>>>> done so that you can use it to experiment yourself
>>>> in order to learn?

>>> No.

>> Okay, then why?

> Because I am not interested in learning how to automate
> dice feeds to bots.

Obviously you didn't even read what I wrote in my previous
post wanting to understand, nor what I wrote in bug-gnubg
mail-list about the experiments I was proposing. It's never
too late to read it. Here is the link again:

https://lists.gnu.org/archive/html/bug-gnubg/2022-09/msg00003.html

As for simulating manual dice, after suggesting the idea, I
went ahead myself to write and poste here simple codes to
do it in more than one way. I even shared the EXE file in my
backgammon site.

>>>> 3) Most importantly, don't you have nothing to say about
>>>> the essence of the experiments that I'm suggesting? Do

>>> No.

>> Okay, fine. You sure have your right to be a brainless idiot.

> Because I disagree with your methods, I'm a brainless idiot.

Not because "you disagreed" with my ideas and suggestions
but because "you didn't even bother to disagree" (nor to make
any comments for that matter), before you started "yawning".

>>>> you understand what they could reveal? Etc.? Please
>>>> try to give an elaborate answer that may be useful to
>>>> us all, instead of your pathetic, brainless one-liners... :(

>>> No.

>> Okay, fine. You sure have your right to be a brainless asshole.

> Because I'm not interested in your conspiracy theories, I'm a
> brainless asshole. Ok, thanks, got it.

They were not "conspiracy theories". I don't think that you even
understand what these words mean. I was suggesting that new
simple (and easy to code) features should be added to Gnubg,
so that people could repeat Axel's half-ass experiments (which
I had suggested for years that you all should do for yourselves),
and even do other experiments in various compbinations.

I know that you believers are afraid to find out that there is no
Santa :) which is not a problem for me. I was trying to create a
conversation, an interest in discovering, learning what you don't
know. You cetainly have a right to not be interested in my ideas
but then you don't need to engage in the conversation just to be
an asshole towards me...

"What goes around comes around" is true for all of us and so
is true "What comes around goes around".

MK

[Nasti Chestikov]

On Monday, 26 September 2022 at 23:00:23 UTC+1, Simon Woodhead wrote:

> I already know plenty of things that are interesting about myself.
>

I am sure.

A surname like Woodhead will mean you had to endure much pain whilst going through school.

The insults alone are not good. Kids can be very cruel.

Those insults can shape your outlook on life.

You start to believe everyone is out to get you, it's not a happy place o be.....I *do* sympathise.