Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Here is how gnubg cheats.
3,198 views
Skip to first unread message
muratk
Apr 5, 2012, 6:56:43 AM4/5/12
to
Let me warn you that this will be necessarily a long article but if
you take time to read it, you probably will learn something from it.
The reason I am being humble enough to say "probably" instead of
saying "for sure", is that I have no idea about the brain capacity of
all who will be reading it.
But don't you worry. I will try to spell it all out for you as much as
I can. So, let's get started by looking at a position.
====================================================
GNU Backgammon Position ID: u3PDAADvtgHAAA
Match ID : MIHxAAAAAAAE
+-1--2--3--4--5--6-------7--8--9-10-11-12-+ O: gnubg
| O O O O O | | | 0 points
| O O O O O | | | Rolled 34
| O O | | |
| O | | |
| | | |
| |BAR| |^ 7 point match (Cube:
1)
| | | |
| | | |
| X X X | | |
| X X X X X | | O X |
| X X X X X | | O X | 0 points
+24-23-22-21-20-19------18-17-16-15-14-13-+ X: Murat7F01
====================================================
In this positin gnugb played 18/11 which raised my eyebrow. This is
the kind of position that I have been talking about when claiming that
I can predict future dice rolls playing against gnubg and other bots.
At this point let's tie a couple of loose ends so that you can focus
better. Whether admitted or not, all bg bots today are mutated
offsprings of jellyfish.
Jellyfish was cheating. When I reported in this forum that it was
rolling 77's, the dice rolling bug was fixed but at the same time
jellyfish started to play differently. Thus, the link between how
jellyfish rolled dice and how it played was established. After that,
the guy who was peddling jellyfish disappeared from the face of the
planet and jellyfish has been flushed down into the backgammon septic
tank.
And you may be wondering why I wanted to play cubeless 7-point matches
to begin with? Well, I was not only just upset but also curious about
not being able to play cubeless backgammon (i.e. "the real thing"
before it was bastardized by sick gambler Americans) using commercial
bots like extereme gammon. So, I decided to see if I could find any
answers by playing cubeless 7-point matches against gnubg.
I downloaded 10x10,000 rolls from the random.org, saved them in 10
different files, poured myself a cup of tea, got comfortable in my
chair and started to play, intending to play 10 matches using each
file, for a total of 100 matches, to observe what would happen.
The above position arose at the 14th move, of the first game, of the
first match. An unfortunately early lucky strike, you may say... :(
After gnubg played 18/11, I rolled 32 and the correct play for me was
to hit, after which gnubg would roll a decisive joker 64!
Now, after rasining my eyebrow about gnubg playing 18/11, I would have
done one or both of two things.
If I had bet money on winning the game/match, I would play my 32
"incorrectly" (i.e. make an inferior move, just like gnubg has made)
in order to avoid gnubg's following 64 joker.
If I was betting money to predict future rolls, I would bet a
reasonable amount that I could afford to lose, let's say $100, on the
2 in 36 odds that it would get a 64... That is your $1,700 against my
$100. After I hit you with a few of these, you all would start to shit
your pants... ;)
All a person needs to predict future dice rolls playing against bots
is to be a good enough backgammon player to detect such subtle
irregularities be able to ask oneself "why has the bot played like
this" in any similar position.
According to the hint, 18/11 is the right move with 46.91% vs. the
second best move 5/2 5/1 with 46.86%. A mere 0.05% difference. And if
you roll out, the difference shrinks to 0.03%, between 46.85% and
46.82%.
But I am still not convinced. So, I take a closer look at the default
grandmaster settings. Under the advanced options, there is a box
checked, that says "for cubeful evaluations, use cubeful checker
evaluation".
Because I am playing cubeless 7-point matches, it sounds like an
irrelevant setting in this case but I check it off in both the payer
and the analysis and then roll out again, just to see.
Holy macaroney! The formerly second best move 5/2 5/1 is now superior
to 18/11 by 46.78% vs. 46.71%, by 0.07% which is a bigger difference
than any of the above.
Okay, well, let's leave these settings alone and start replaying from
the beginning. Curiously, on its 12th move, (one before the above
position), gnubg plays 18/7 instead of 7/1 6/1.
The hint says it's the right move with 50.08% vs. 50.01%. Although by
a smaller margin, the roll outs validate it with 50.18% vs. 50.14%.
Now, lets revert that one settings and roll out again. Sure enough,
the second best move reverts to being the best move with 50.06% vs.
49.95%.
So, what can we conclude from all this?
First, the bots don't seem to know how to play without the cube. My
personal observation is that the dice seems more realistic playing
without the cube, which may just be my biased impression. But I do
better against gnubg without the cube, which is a tangible evidence.
And, come to think of it, bots like "extreme garbage" seem to not even
offer the option of cubeless play because they probably don't know how
to handle the above discrepancy in their colorful pie chart rendition
of meaningless analyses...
Which leads to my second conclusion, that it doesn't matter to me
either way, simply because I look at the cube as a tool for impatient
sick gamblers to raise the stakes and expedite their wins or losses...
Consequently, any analysis that is based on the so-called cube skill
is nothing more than plain bullshit. In fact, a pile of bullshit that
one can use to his advantage when playing against these bots and/or
betting money on predicting future dice rolls (regardless of how the
dice is rolled).
In the past, I had proposed that the "doubling window" gave the bots
the wiggle room they needed to cheat (as I define "cheat"). Now, I
have the proof.
From now on, in any betting on predicting future dice rolls, I will
insists that we use the default settings (i.e. leave the box "for
cubeful evaluations, use cubeful checker evaluation" checked even when
playing cubeless matches.
I suppose I should uncheck it if I want to play truly cubeless matches
against gnubg but even then, who knows what other bullshit settings
effect its other bullshit anayses...? It may be just best to ignore
them all.
My advice to people who are just learning backgammon is to learn to
play it without the cube first. Learn the real game first and then if
you want to become a sick gambler, you can always use the cube to jack
up the stakes, in order to win or lose faster...! :)) But, learn to
have to patiently play out a game to the end without the cube, and
thus improve your staying power.
Playing backgammon as it has been for millenia without the cube is
like making slow love to your wife.
Playing backgammon with the cube is like fast fucking a whore, with
much of what you pay going to the book publishing, bot peddling,
tournament organizing pimps of backgammon gambling......
MK
you take time to read it, you probably will learn something from it.
The reason I am being humble enough to say "probably" instead of
saying "for sure", is that I have no idea about the brain capacity of
all who will be reading it.
But don't you worry. I will try to spell it all out for you as much as
I can. So, let's get started by looking at a position.
====================================================
GNU Backgammon Position ID: u3PDAADvtgHAAA
Match ID : MIHxAAAAAAAE
+-1--2--3--4--5--6-------7--8--9-10-11-12-+ O: gnubg
| O O O O O | | | 0 points
| O O O O O | | | Rolled 34
| O O | | |
| O | | |
| | | |
| |BAR| |^ 7 point match (Cube:
1)
| | | |
| | | |
| X X X | | |
| X X X X X | | O X |
| X X X X X | | O X | 0 points
+24-23-22-21-20-19------18-17-16-15-14-13-+ X: Murat7F01
====================================================
In this positin gnugb played 18/11 which raised my eyebrow. This is
the kind of position that I have been talking about when claiming that
I can predict future dice rolls playing against gnubg and other bots.
At this point let's tie a couple of loose ends so that you can focus
better. Whether admitted or not, all bg bots today are mutated
offsprings of jellyfish.
Jellyfish was cheating. When I reported in this forum that it was
rolling 77's, the dice rolling bug was fixed but at the same time
jellyfish started to play differently. Thus, the link between how
jellyfish rolled dice and how it played was established. After that,
the guy who was peddling jellyfish disappeared from the face of the
planet and jellyfish has been flushed down into the backgammon septic
tank.
And you may be wondering why I wanted to play cubeless 7-point matches
to begin with? Well, I was not only just upset but also curious about
not being able to play cubeless backgammon (i.e. "the real thing"
before it was bastardized by sick gambler Americans) using commercial
bots like extereme gammon. So, I decided to see if I could find any
answers by playing cubeless 7-point matches against gnubg.
I downloaded 10x10,000 rolls from the random.org, saved them in 10
different files, poured myself a cup of tea, got comfortable in my
chair and started to play, intending to play 10 matches using each
file, for a total of 100 matches, to observe what would happen.
The above position arose at the 14th move, of the first game, of the
first match. An unfortunately early lucky strike, you may say... :(
After gnubg played 18/11, I rolled 32 and the correct play for me was
to hit, after which gnubg would roll a decisive joker 64!
Now, after rasining my eyebrow about gnubg playing 18/11, I would have
done one or both of two things.
If I had bet money on winning the game/match, I would play my 32
"incorrectly" (i.e. make an inferior move, just like gnubg has made)
in order to avoid gnubg's following 64 joker.
If I was betting money to predict future rolls, I would bet a
reasonable amount that I could afford to lose, let's say $100, on the
2 in 36 odds that it would get a 64... That is your $1,700 against my
$100. After I hit you with a few of these, you all would start to shit
your pants... ;)
All a person needs to predict future dice rolls playing against bots
is to be a good enough backgammon player to detect such subtle
irregularities be able to ask oneself "why has the bot played like
this" in any similar position.
According to the hint, 18/11 is the right move with 46.91% vs. the
second best move 5/2 5/1 with 46.86%. A mere 0.05% difference. And if
you roll out, the difference shrinks to 0.03%, between 46.85% and
46.82%.
But I am still not convinced. So, I take a closer look at the default
grandmaster settings. Under the advanced options, there is a box
checked, that says "for cubeful evaluations, use cubeful checker
evaluation".
Because I am playing cubeless 7-point matches, it sounds like an
irrelevant setting in this case but I check it off in both the payer
and the analysis and then roll out again, just to see.
Holy macaroney! The formerly second best move 5/2 5/1 is now superior
to 18/11 by 46.78% vs. 46.71%, by 0.07% which is a bigger difference
than any of the above.
Okay, well, let's leave these settings alone and start replaying from
the beginning. Curiously, on its 12th move, (one before the above
position), gnubg plays 18/7 instead of 7/1 6/1.
The hint says it's the right move with 50.08% vs. 50.01%. Although by
a smaller margin, the roll outs validate it with 50.18% vs. 50.14%.
Now, lets revert that one settings and roll out again. Sure enough,
the second best move reverts to being the best move with 50.06% vs.
49.95%.
So, what can we conclude from all this?
First, the bots don't seem to know how to play without the cube. My
personal observation is that the dice seems more realistic playing
without the cube, which may just be my biased impression. But I do
better against gnubg without the cube, which is a tangible evidence.
And, come to think of it, bots like "extreme garbage" seem to not even
offer the option of cubeless play because they probably don't know how
to handle the above discrepancy in their colorful pie chart rendition
of meaningless analyses...
Which leads to my second conclusion, that it doesn't matter to me
either way, simply because I look at the cube as a tool for impatient
sick gamblers to raise the stakes and expedite their wins or losses...
Consequently, any analysis that is based on the so-called cube skill
is nothing more than plain bullshit. In fact, a pile of bullshit that
one can use to his advantage when playing against these bots and/or
betting money on predicting future dice rolls (regardless of how the
dice is rolled).
In the past, I had proposed that the "doubling window" gave the bots
the wiggle room they needed to cheat (as I define "cheat"). Now, I
have the proof.
From now on, in any betting on predicting future dice rolls, I will
insists that we use the default settings (i.e. leave the box "for
cubeful evaluations, use cubeful checker evaluation" checked even when
playing cubeless matches.
I suppose I should uncheck it if I want to play truly cubeless matches
against gnubg but even then, who knows what other bullshit settings
effect its other bullshit anayses...? It may be just best to ignore
them all.
My advice to people who are just learning backgammon is to learn to
play it without the cube first. Learn the real game first and then if
you want to become a sick gambler, you can always use the cube to jack
up the stakes, in order to win or lose faster...! :)) But, learn to
have to patiently play out a game to the end without the cube, and
thus improve your staying power.
Playing backgammon as it has been for millenia without the cube is
like making slow love to your wife.
Playing backgammon with the cube is like fast fucking a whore, with
much of what you pay going to the book publishing, bot peddling,
tournament organizing pimps of backgammon gambling......
MK
Message has been deleted
Stick
Apr 5, 2012, 12:00:53 PM4/5/12
to
You can play cubeless matches with XG.
Stick
muratk
Apr 10, 2012, 3:13:24 AM4/10/12
to
Did I confuse it with snowie then? One of those bots doesn't have
the option to play cubeless matches, no?
Anyway, I don't have the patience to play against bots with manual
dice and XG is a hilarious piece of shit regardless of what built
in dice it uses.
And yes, my offer to bet money on predicting XG's or any other bot's
built in dice rolls is still valid...
MK
the option to play cubeless matches, no?
Anyway, I don't have the patience to play against bots with manual
dice and XG is a hilarious piece of shit regardless of what built
in dice it uses.
And yes, my offer to bet money on predicting XG's or any other bot's
built in dice rolls is still valid...
MK
LENUS
Apr 14, 2012, 3:29:09 AM4/14/12
to
On Apr 10, 11:13 am, muratk <mu...@compuplus.net> wrote:
>
>
> And yes, my offer to bet money on predicting XG's or any other bot's
> built in dice rolls is still valid...
>
> MK
Murat,
>
>
> And yes, my offer to bet money on predicting XG's or any other bot's
> built in dice rolls is still valid...
>
> MK
You are offering nothing unusual or surprising, chances of rolling 64
(or any other non-double) REALLY IS 2 out of 36, if you care to make
adjustment to the bet terms, let us know.
muratk
Apr 15, 2012, 4:37:45 AM4/15/12
to
On Apr 14, 1:29 am, LENUS <lenus...@yahoo.com> wrote:
.
.
.
Lenus, I think you are fooled be the ilks of Tim Chow to
reduce backgammon to the level of tossing coins...
We are not talking about how often I can predict a 64
while simply rolling dice but we are talking about the
likelihood of one side or another rolling a 64 in a very
specific position during a game of backgammon...
Do you understand the difference...?
Please answer yes or no before you write anything more...
Thanks,
MK
.
.
> You are offering nothing unusual or surprising, chances
> of rolling 64 (or any other non-double) REALLY IS 2 out
> of 36, if you care to make adjustment to the bet terms,
> let us know.
.
> of rolling 64 (or any other non-double) REALLY IS 2 out
> of 36, if you care to make adjustment to the bet terms,
> let us know.
.
Lenus, I think you are fooled be the ilks of Tim Chow to
reduce backgammon to the level of tossing coins...
We are not talking about how often I can predict a 64
while simply rolling dice but we are talking about the
likelihood of one side or another rolling a 64 in a very
specific position during a game of backgammon...
Do you understand the difference...?
Please answer yes or no before you write anything more...
Thanks,
MK
valerie...@gmail.com
Mar 18, 2015, 10:34:43 AM3/18/15
to
Message has been deleted
jrobin...@gmail.com
Jun 23, 2015, 12:46:20 PM6/23/15
to
Playing against a bot that is excessively 'fortunate' with the dice it rolls is really bad for beginners because it teaches them to be over cautious.
GNU backgammon is just as irritating as Jellyfish, a pox on both their houses!
GNU backgammon is just as irritating as Jellyfish, a pox on both their houses!
thefishd...@gmail.com
Jun 24, 2019, 5:26:07 PM6/24/19
to
Definitely cheats.
I had a situation where I had 3 points in my home base. Gnu backgammon had 2 pieces in hand. It doubled??? And then rolled double 3. How did it know it was going to roll double 3 to get both men back on board and then manage to hit one of my men?
I had a situation where I had 3 points in my home base. Gnu backgammon had 2 pieces in hand. It doubled??? And then rolled double 3. How did it know it was going to roll double 3 to get both men back on board and then manage to hit one of my men?
bgbl...@googlemail.com
Jul 27, 2019, 6:44:51 PM7/27/19
to
Am Montag, 24. Juni 2019 23:26:07 UTC+2 schrieb thefish...@gmail.com:
> Definitely cheats.
>
> I had a situation where I had 3 points in my home base. Gnu backgammon had 2 pieces in hand. It doubled??? And then rolled double 3. How did it know it was going to roll double 3 to get both men back on board and then manage to hit one of my men?
Maybe because you were primed and it was pretty irrelevant whether the bot comes in or not?
> Definitely cheats.
>
> I had a situation where I had 3 points in my home base. Gnu backgammon had 2 pieces in hand. It doubled??? And then rolled double 3. How did it know it was going to roll double 3 to get both men back on board and then manage to hit one of my men?
Without posting a positions complaints are pointless.
Simply set up the position again, change the seed of the random number generator and check whether the bot doubles again. do this some dozen times. Complain and post the position then if the bot behaved not always the same. This might be something worth to investigate....
bgbl...@googlemail.com
Jul 27, 2019, 6:48:05 PM7/27/19
to
Am Dienstag, 23. Juni 2015 18:46:20 UTC+2 schrieb jrobin...@gmail.com:
> Playing against a bot that is excessively 'fortunate' with the dice it rolls is really bad for beginners because it teaches them to be over cautious.
It might be surprising to you: to move the checkers in a way that more rolls work well, aka are lucky, is the very essence of the game.
> Playing against a bot that is excessively 'fortunate' with the dice it rolls is really bad for beginners because it teaches them to be over cautious.
It is really difficult to make a bot play weak like a human. Do you believe that such unnatural play is better for beginners?
IMHO having real time feedback on the dice quality is a good trainer and not playing weak,
kevin arbuthnot
Feb 2, 2021, 8:30:04 AM2/2/21
to
On Saturday, 27 July 2019 at 23:48:05 UTC+1, bgbl...@googlemail.com wrote:
> Am Dienstag, 23. Juni 2015 18:46:20 UTC+2 schrieb jrobin...@gmail.com:
> It might be surprising to you: to move the checkers in a way that more rolls work well, aka are lucky, is the very essence of the game.
>
> It is really difficult to make a bot play weak like a human. Do you believe that such unnatural play is better for beginners?
Although I've been playing for a few decades I don't rate myself as great, so when I first started using Gnu a few years ago, I wasn't immediately shocked to be losing a lot when I set Gnu to stronger levels, as I wanted to learn. After many games, however, I did start to be surprised by a few things.
> Am Dienstag, 23. Juni 2015 18:46:20 UTC+2 schrieb jrobin...@gmail.com:
> It might be surprising to you: to move the checkers in a way that more rolls work well, aka are lucky, is the very essence of the game.
>
> It is really difficult to make a bot play weak like a human. Do you believe that such unnatural play is better for beginners?
First, if I set it at a low level in the early days, just to get used to it, eg, beginner or casual player, it would do stupid things, like accepting doubles from clearly losing positions, or offer doubles from the same positions, or make blatantly stupid moves in order to lose.
Second, when I set it to middling levels it would play well and all would seem well, until you accepted a double that it "thought" you shouldn't have accepted, eg, a 20% chance of winning, even though I had a stronger layout, and Gnu could only get ahead by throwing jokers. Well that happened a real lot. It was almost trying to dissuade you from taking any risk and punishing you for a poor decision. I wasn't sure how much it was being "lucky", so played 2000+ games and recorded the outcomes. My recent analysis of the results suggests that if I accept a double in these circumstances, ie when it would recommend that I do not accept, from that point onwards, Gnu will average 13.6 pips per throw, and I will average 7.4. That's a bit spooky, innit?
Using Gnu's own analysis tool, about 4 times out of 5 Gnu enjoys more "luck" than I did, often in the 20% range!
I also think that the analysis tool should show a total pip count thrown by each player for each game; that reveals a lot.
Nasti Chestikov
Feb 2, 2021, 12:31:58 PM2/2/21
to
Having said that, when I can compile the source code back to the same filesize / hashsum as the currently live version then I'll take GNUDung as being honest.
But I can't. So, it sits in my "this piece of crap cheats" drawer.
Thunderground Samurai
Aug 31, 2021, 1:23:53 PM8/31/21
to
Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.
Nasti Chestikov
Sep 14, 2021, 12:15:47 PM9/14/21
to
On Tuesday, 31 August 2021 at 18:23:53 UTC+1, Thunderground Samurai wrote:
> GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, > to turn a losing position into a winning one. This happens far too often to be random. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no > > > luck.
> Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.
From your main menu: View <-> Panels <-> Command
> GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, > to turn a losing position into a winning one. This happens far too often to be random. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no > > > luck.
> Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.
It will pop up a dialogue box in the bottom right hand corner of your screen. Type "show RNG" and then "show seed". That gets you the parameters used for the dice.
Save down your game and then close down GNU Backgammon. Upon restarting, choose those parameters for the dice (before rolling anything). You can then see if the dice are the same as you play differently.
Frank Berger
Sep 22, 2021, 3:46:47 PM9/22/21
to
Thunderground Samurai schrieb am Dienstag, 31. August 2021 um 19:23:53 UTC+2:
> GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, to turn a losing position into a winning one. This happens far too often to be random. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no luck.
> Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.
That's the long awaited proof. 3 doubles in a row or 3 out of 4 rools. In the 40 years I play backgammon I have never seen this in RL. Never. What clever bastards that programmers are, providing the source code so that everyone can check the code.
> GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, to turn a losing position into a winning one. This happens far too often to be random. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no luck.
> Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.
Ricardo Costa
Jun 10, 2023, 11:17:19 PM6/10/23
to
A good test would be to roll physical dice and then let gnugb know the results of the rolls. I'm curious if it would ever win under those circumstances. Is that possible with the current code?
peps...@gmail.com
Jun 11, 2023, 7:00:38 AM6/11/23
to
Paul
Frank Berger
Jun 11, 2023, 5:06:33 PM6/11/23
to
Ricardo Costa schrieb am Sonntag, 11. Juni 2023 um 05:17:19 UTC+2:
> 100% cheats. The rolls it gets after a doubling cube challenge have been accepted are off the chain.
And how stupid so many people must have been for such a long time, not finding the cheating code in GnuBG
> 100% cheats. The rolls it gets after a doubling cube challenge have been accepted are off the chain.
>The program wins far too often considering its otherwise suspect tactics.
>Moving pips forward instead of pulling them off? Doubling basically automatically when you don't land a hit pip?
> A good test would be to roll physical dice and then let gnugb know the results of the rolls. I'm curious if it would ever win under those circumstances. Is that possible with the current code?
Axel Reichert
Jun 11, 2023, 5:20:34 PM6/11/23
to
Ricardo Costa <hdvpro...@gmail.com> writes:
> The program wins far too often considering its otherwise suspect
> tactics.
Maybe it is YOUR tactics that is suspect?
> The program wins far too often considering its otherwise suspect
> tactics.
> A good test would be to roll physical dice and then let gnugb know the
> results of the rolls. I'm curious if it would ever win under those
> circumstances. Is that possible with the current code?
not cheat (however tempting it may be in particular situations), and
lose against GNU Backgammon as before, a fate you share with most
humans.
Axel
P.S.: If you are serious in your endeavour, there is also an official
complaint form for backgammon software, easily googled.
Ricardo Costa
Jun 12, 2023, 11:23:08 AM6/12/23
to
Axel Reichert
Jun 12, 2023, 5:36:58 PM6/12/23
to
Ricardo Costa <hdvpro...@gmail.com> writes:
> Where is the setting for manual dice? I'm not seeing it.
Several of the buzz words already match:
> Where is the setting for manual dice? I'm not seeing it.
Settings, Options, Dice, Manual Dice
And please also google "All about GNU Backgammon".
Axel
Ricardo Costa
Jun 13, 2023, 10:45:55 PM6/13/23
to
Ricardo Costa
Jun 13, 2023, 10:50:01 PM6/13/23
to
MK
Jun 21, 2023, 4:58:39 AM6/21/23
to
On June 11, 2023 at 5:00:38 AM UTC-6, peps...@gmail.com wrote:
> Could you give us an example of gnubg's bad
> play (or "suspect tactics")? This is different to
> the question of luck. Can you give an example
> of where gnubg actually played badly?
Paul, this thread goes back 11 years, to 2012
> Could you give us an example of gnubg's bad
> play (or "suspect tactics")? This is different to
> the question of luck. Can you give an example
> of where gnubg actually played badly?
when I had initiated it with some examples. I
don't know if they could be proof of Noo-BG's
bad plays but they certainly can be considered
"suspect moves".
Here are a couple of examples of suspect plays
that I encountered not long ago, experimenting
with two instances of Noo-BG open, one getting
dice rolls from a file an the other being fed the
same dice rolls manually, with all other settings
being exactly the same:
game 2 move 31
Dice from file: bPcAqQA3AAAAAA:QQkFAEAAAAAE
Manual entry: bPcAQwE3AAAAAA:QQkFAEAAAAAE
game 3 move 25
Dice from file: btuTAAABAAAAAA:QYkKAEAAIAAE
Manual entry: tt0rAAABAAAAAA:QYkKAEAAIAAE
In both cases Noo-BG has zero chance of winning
and apparently makes the first move it evaluates,
as one of moves all with zero equity. But in the two
instances of the process, it makes different moves!
Unless one keeps a suspicious eye on the bots, it's
unlikely that they will see anything suspicious. But
when one does notice such moves, then he would
be well justified to not share the same trusting of
the bots as with you guys and he may also be well
justified to suspect "what else"...
I personally thing Noo-BG looks ahead before cube
decisions, like Ex-Gee and actually more obviously
but since it doesn't allow external dice DLL's, we can't
test if it makes multiple and/or multithreaded calls
like Ex-Gee does.
I suggest you guys don't rush to bash bot suspecters
before you make genuine efforts to acknowledge and
reasonably explain what causes those suspicions.
MK
MK
Jun 21, 2023, 5:16:21 AM6/21/23
to
On June 11, 2023 at 3:06:33 PM UTC-6, Frank Berger wrote:
> And how stupid so many people must have
> been for such a long time, not finding the
> cheating code in GnuBG
It's very possible that people who may have
> And how stupid so many people must have
> been for such a long time, not finding the
> cheating code in GnuBG
looked for it weren't capable of finding it.
On the other hand, people like you who may
be capable of finding it probably nefer felt a
need to look for because they assumed that
it wouldn't be there.
Give me an honest answer. Have you ever
combed through Noo-BG's code looking for
evidence of cheating?
And a bonus question, how can you be sure
that the executable distributed matches the
source code that you would be looking at??
> GnuBG plays a PR of about 0,45 (IIRC) and
> there are about 10 human players worldwide
This is a circular fallacy. You can't measure a
measuring stick against itself as the measuring
unit.
Will you bet money on Noo-BG based on my
expected winning chances derived from my
PR calculated by Noo-BG? If not, shut up and
fuck off!
> I'm not sure I got it. Are you asking for entering
> manual dice? Yes you can do it. And this is one
> recommended approach.
to automate manual dice which is very tedious
and thus probably hardly ever used.
> Another approach would be to try to understand
> what a pseudo-random-number generator is and
> what a seed is.
with manual dice wouldn't cheat with internal
dice is like saying that people who are already
rich wouldn't steal. Learn to think unconditionedly,
unassumedly...
MK
MK
Jun 21, 2023, 5:25:17 AM6/21/23
to
On June 11, 2023 at 3:20:34 PM UTC-6, Axel Reichert wrote:
> P.S.: If you are serious in your endeavour,
> there is also an official complaint form for
> backgammon software, easily googled.
I think the creator of that form, Gary wong,
> P.S.: If you are serious in your endeavour,
> there is also an official complaint form for
> backgammon software, easily googled.
also among the creators of Noo-BG, was
the biggest, most-insulting asshole of all
time in RGB. Some of the items in his form
had already been proven at the time he had
created it but, of course, that didn't matter.
Do you think he would bet money on his
own bot if someone offered to provide
circumstantial evidence for it? How about
you? Would you bet monet on that Noo-BG
doesn't cheat?
MK
peps...@gmail.com
Jun 21, 2023, 1:49:16 PM6/21/23
to
On Wednesday, June 21, 2023 at 10:16:21 AM UTC+1, MK wrote:
...
This is actually a good point by Murat.
The PR measures how accurately someone follows the bot.
So using gnubg's PR to assess gnubg isn't really a valid test.
For those that believe in market efficiency, a wealthy person
can offer to back gnubg in a money session against any taker,
and point out that no one accepts the offer.
Or a few ultra long matches can be played, or many short matches,
against top humans and we can see what happens.
Gnubg needs to eat ham and mustard sandwiches before playing at its best.
Therefore no test is valid unless a graphic of a ham and mustard sandwich
is displaying on one of the user's monitors.
Paul
...
> > GnuBG plays a PR of about 0,45 (IIRC) and
> > there are about 10 human players worldwide
> > able to play below 3 on average ....
>
> This is a circular fallacy. You can't measure a
> measuring stick against itself as the measuring
> unit.
...
> > there are about 10 human players worldwide
> > able to play below 3 on average ....
>
> This is a circular fallacy. You can't measure a
> measuring stick against itself as the measuring
> unit.
This is actually a good point by Murat.
The PR measures how accurately someone follows the bot.
So using gnubg's PR to assess gnubg isn't really a valid test.
For those that believe in market efficiency, a wealthy person
can offer to back gnubg in a money session against any taker,
and point out that no one accepts the offer.
Or a few ultra long matches can be played, or many short matches,
against top humans and we can see what happens.
Gnubg needs to eat ham and mustard sandwiches before playing at its best.
Therefore no test is valid unless a graphic of a ham and mustard sandwich
is displaying on one of the user's monitors.
Paul
MK
Jun 21, 2023, 5:01:03 PM6/21/23
to
On June 21, 2023 at 11:49:16 AM UTC-6, peps...@gmail.com wrote:
> On Wednesday, June 21, 2023 at 10:16:21 AM UTC+1, MK wrote:
>>> GnuBG plays a PR of about 0,45 (IIRC) and
>>> there are about 10 human players worldwide
>>> able to play below 3 on average ....
>> This is a circular fallacy. You can't measure a
>> measuring stick against itself as the measuring
>> unit.
> On Wednesday, June 21, 2023 at 10:16:21 AM UTC+1, MK wrote:
>>> GnuBG plays a PR of about 0,45 (IIRC) and
>>> there are about 10 human players worldwide
>>> able to play below 3 on average ....
>> This is a circular fallacy. You can't measure a
>> measuring stick against itself as the measuring
>> unit.
> This is actually a good point by Murat.
> The PR measures how accurately someone
> follows the bot. So using gnubg's PR
> to assess gnubg isn't really a valid test.
> For those that believe in market efficiency,
This would exclude people who can't afford
> The PR measures how accurately someone
> follows the bot. So using gnubg's PR
> to assess gnubg isn't really a valid test.
> For those that believe in market efficiency,
and/or who don't want to gamble (since it's
a game of luck afterall).
> a wealthy person can offer to back gnubg
> in a money session against any taker, and
> point out that no one accepts the offer.
A wealthy person can offer a sum assuming
that he will lose it but being okay with that
for the good cause of promoting the game.
A person who really believes that no human
can beat a certain bot, doesn't even need to
be wealthy in order to offer a prize sum since
he wouldn't be risking to lose it.
> Or a few ultra long matches can be played,
> or many short matches, against top humans
> and we can see what happens.
of mentally ill gambler "giants", then it will be
an exclusive "by invitation only" masturbation
contest among prequalified ones by the bots.
> Gnubg needs to eat ham and mustard
It sounds like you have been eating too many
fried brain sandwiches with mustard... :(
https://duckduckgo.com/?q=fried+brain+sandwich&ia=web
MK
Philippe Michel
Jun 21, 2023, 5:43:42 PM6/21/23
to
On 2023-06-21, MK <mu...@compuplus.net> wrote:
> I personally thing Noo-BG looks ahead before cube
> decisions, like Ex-Gee and actually more obviously
> but since it doesn't allow external dice DLL's, we can't
> test if it makes multiple and/or multithreaded calls
> like Ex-Gee does.
With gnubg it should be possible to generate dice with a user-provided
> I personally thing Noo-BG looks ahead before cube
> decisions, like Ex-Gee and actually more obviously
> but since it doesn't allow external dice DLL's, we can't
> test if it makes multiple and/or multithreaded calls
> like Ex-Gee does.
program by hijacking the "read dice from file" feature, by reading them
from a named pipe.
I confirmed it works on Unix this way:
- create a named pipe:
mkfifo /tmp/p
- write dice generated by an external program to it. I used the
following simple Python script, but anything that writes two numbers
between 1 and 6 per line will do.
from random import randint
while True:
d1 = randint(1, 6)
d2 = randint(1, 6)
print(d1, d2)
# if you fear gnubg discards rolls it doesn't like
# you could log d1 and d2 somewhere here
# and compare this log with the match record
python /tmp/rng.py > /tmp/p
- start gnubg and choose to read the dice from /tmp/p as RNG
It should be possible to do something similar on Windows. It has named
pipes as well but their names are restricted to awkward paths. They
could be tricky to select in the file explorer widget as the file to
read the dice from.
I'd be interested if you or someone else tried this on Windows and
reported how it went.
MK
Jun 21, 2023, 6:46:15 PM6/21/23
to
On June 21, 2023 at 3:43:42 PM UTC-6, Philippe Michel wrote:
> With gnubg it should be possible to generate
> dice with a user-provided program by hijacking
> the "read dice from file" feature, by reading them
> from a named pipe.
> I confirmed it works on Unix this way:
> .....
> With gnubg it should be possible to generate
> dice with a user-provided program by hijacking
> the "read dice from file" feature, by reading them
> from a named pipe.
> I confirmed it works on Unix this way:
> I'd be interested if you or someone else tried
> this on Windows and reported how it went.
Just a couple of quick thoughts/questions
> this on Windows and reported how it went.
before anyone tries it on Windows.
- Before feeding the dice to the pipe, we need
to wait until Noo-BG is done with deciding its
cube decision. If it's followed by a cube action,
it's easy but how would we know if there is no
cube action?
- If we wait too long, because we won't know
when it's ready to read the dice from the pipe,
then it will think it reached the EOF and try to
rewind the file.
With manual dice, it displays a dice dialog box
and waits for input. With reading from a file or
a pipe, it would need to do the same, to enable
the script to wait for a similar "ready to receive
dice" cue.
In that case, it would be easier for Noo-BG to
accept keyboard input for manual dice, which
can be emulated by passing a keyboard event
from a script or a tiny compiled executable. (I
can't understand why you guys refuse to add
this simple, basic capability that exists in every
other stupid bot out there..?)
MK
Philippe Michel
Jun 22, 2023, 4:54:24 PM6/22/23
to
> Just a couple of quick thoughts/questions
> before anyone tries it on Windows.
>
> - Before feeding the dice to the pipe, we need
> to wait until Noo-BG is done with deciding its
> cube decision. If it's followed by a cube action,
> it's easy but how would we know if there is no
> cube action?
>
> - If we wait too long, because we won't know
> when it's ready to read the dice from the pipe,
> then it will think it reached the EOF and try to
> rewind the file.
I'm not sure about Windows, but I would not expect these to be issues.
> before anyone tries it on Windows.
>
> - Before feeding the dice to the pipe, we need
> to wait until Noo-BG is done with deciding its
> cube decision. If it's followed by a cube action,
> it's easy but how would we know if there is no
> cube action?
>
> - If we wait too long, because we won't know
> when it's ready to read the dice from the pipe,
> then it will think it reached the EOF and try to
> rewind the file.
The pipe is a kind of waiting queue. The RNG fills it with dice rolls
then gets blocked. Gnubg consumes them and would get blocked if the pipe
became empty. In practice, after some quantity of dice rolls is read and
the queue is drained enough, the writing RNG gets unblocked and replenish
the queue.
The interest for this use case is that the interface to access both ends
of it is the same as writing and reading a file, with no EOF or disk
full issues, only blocking until the situation sorts itself out or one
of the involved processes is exited.
> In that case, it would be easier for Noo-BG to
> accept keyboard input for manual dice, which
> can be emulated by passing a keyboard event
> from a script or a tiny compiled executable. (I
> can't understand why you guys refuse to add
> this simple, basic capability that exists in every
> other stupid bot out there..?)
I'm a bit skeptical about the advantage of keyboard input (2 keys +
something else, the return key or a click, to validate) vs. one click on
the dicerolls pad.
Maybe I'm biased because I used a French keyboard where the digits are
on shifted keys, but even if this were not the case, or with a numeric
keypad, I tend to think that mixing keyboard and mouse use would be more
cumbersome.
Axel Reichert
Jun 22, 2023, 5:14:24 PM6/22/23
to
MK <mu...@compuplus.net> writes:
> - Before feeding the dice to the pipe, we need
> to wait until Noo-BG is done with deciding its
> cube decision.
[...]
> - Before feeding the dice to the pipe, we need
> to wait until Noo-BG is done with deciding its
> cube decision.
> - If we wait too long, because we won't know
> when it's ready to read the dice from the pipe,
> then it will think it reached the EOF and try to
> rewind the file.
https://en.wikipedia.org/wiki/Anonymous_pipe
Axel
Axel Reichert
Jun 22, 2023, 5:54:47 PM6/22/23
to
MK <mu...@compuplus.net> writes:
> It's very possible that people who may have
> looked for it weren't capable of finding it.
"Judge, there was a murder, but I could not find evidence for it."
> It's very possible that people who may have
> looked for it weren't capable of finding it.
Very convincing.
> Without allowing keyboard input, it's impossible
> to automate manual dice which is very tedious
paranoids, try to fill it via a (named) pipe.
> To suggest that a bot that plays strong enough
> with manual dice wouldn't cheat with internal
> dice is like saying that people who are already
> rich wouldn't steal.
be cheating". If changing to manual dice does not change the severity of
the defeat, it is a strong hint that the bot is not "too strong" for the
(internal) dice to be fair.
Axel
MK
Jun 22, 2023, 8:03:11 PM6/22/23
to
On June 22, 2023 at 2:54:24 PM UTC-6, Philippe Michel wrote:
> On 2023-06-21, MK <mu...@compuplus.net> wrote:
>> - If we wait too long, because we won't know
>> when it's ready to read the dice from the pipe,
>> then it will think it reached the EOF and try to
>> rewind the file.
> I'm not sure about Windows, but I would not
> expect these to be issues. The pipe is a kind
> of waiting queue. The RNG fills it with dice rolls
> then gets blocked. Gnubg consumes them and
> would get blocked if the pipe became empty.
Then, what's the difference between reading
> On 2023-06-21, MK <mu...@compuplus.net> wrote:
>> - If we wait too long, because we won't know
>> when it's ready to read the dice from the pipe,
>> then it will think it reached the EOF and try to
>> rewind the file.
> I'm not sure about Windows, but I would not
> expect these to be issues. The pipe is a kind
> of waiting queue. The RNG fills it with dice rolls
> then gets blocked. Gnubg consumes them and
> would get blocked if the pipe became empty.
from a file and from a pipe? The idea was to
prevent the bot from looking at the upcoming
dice rolls before it makes its cube decision.
"Filling" the pipe with defeats this purpose.
> The interest for this use case is that the
> interface to access both ends of it is the
> same as writing and reading a file, with no
> EOF or disk full issues, only blocking until
> the situation sorts itself out or one of the
> involved processes is exited.
a time can avoid technical problems but the
idea is to give each dice roll to the bot after
it finishes its cube decision. Without a "cue"
from the bot, the blocked writing process will
wait forever and the blocked reading side will
also wait forever...
>> (I can't understand why you guys refuse to
>> add this simple, basic capability that exists
>> in every other stupid bot out there..?)
> GUI programming is not my cup of tea.
> Maybe someone else will do it.
Noo-BG already accepts keyboard input for
all kinds of other user actions.
> I'm a bit skeptical about the advantage of
> keyboard input (2 keys + something else,
> the return key or a click, to validate)
> vs. one click on the dicerolls pad.
trivially easy to automate sending keystrokes
but practically impossible to automate sending
mouse clicks on dice icons at different relative
screen coordinates.
> I tend to think that mixing keyboard and
> mouse use would be more cumbersome.
said, even the stupidest bots implement both.
If not both, then it's the mouse input that will
be the missing feature, as it's the hardest of
the two to implement.
MK
MK
Jun 22, 2023, 8:15:42 PM6/22/23
to
On June 22, 2023 at 3:14:24 PM UTC-6, Axel Reichert wrote:
> MK <mu...@compuplus.net> writes:
>> - Before feeding the dice to the pipe, we need
>> to wait until Noo-BG is done with deciding its
>> cube decision.
> [...]
>> - If we wait too long, because we won't know
>> when it's ready to read the dice from the pipe,
>> then it will think it reached the EOF and try to
>> rewind the file.
> A pipe is not a file.
It is a file, written to and read from using the
> MK <mu...@compuplus.net> writes:
>> - Before feeding the dice to the pipe, we need
>> to wait until Noo-BG is done with deciding its
>> cube decision.
> [...]
>> - If we wait too long, because we won't know
>> when it's ready to read the dice from the pipe,
>> then it will think it reached the EOF and try to
>> rewind the file.
> A pipe is not a file.
same functions as any other file.
> https://en.wikipedia.org/wiki/Anonymous_pipe
Philippe was talking about "named pipes" and
you give a link to "anonymous pipes". They are
not the same. Depending on the modes, a read
function may wait or return EOF/null byte. Why
do you always complicate the discussion with
things that are not essential to the subject..? :(
Making it read from any kind of pipe won't keep
the bot from looking ahead before cube actions
if the dice roll is written to the pipe beforehand!
MK
MK
Jun 22, 2023, 8:33:21 PM6/22/23
to
On June 22, 2023 at 3:54:47 PM UTC-6, Axel Reichert wrote:
> MK <mu...@compuplus.net> writes:
>> It's very possible that people who may have
>> looked for it weren't capable of finding it.
> "Judge, there was a murder, but I could not
> find evidence for it."
> Very convincing.
You fail to understand the logical argument.
> MK <mu...@compuplus.net> writes:
>> It's very possible that people who may have
>> looked for it weren't capable of finding it.
> "Judge, there was a murder, but I could not
> find evidence for it."
> Very convincing.
> Nope. Been there, done that. Read the dice
> from a file. For the paranoids, try to fill it via
> a (named) pipe.
manual dice, reading from a file or a pipe is not
a "solution" to preventing the bot from looking
ahead, which was the original intentention.
>> To suggest that a bot that plays strong enough
>> with manual dice wouldn't cheat with internal
>> dice is like saying that people who are already
>> rich wouldn't steal.
> If changing to manual dice does not change
> the severity of the defeat, it is a strong hint
> that the bot is not "too strong" for the (internal)
> dice to be fair.
You went from asking for "evidence" to settling
> the severity of the defeat, it is a strong hint
> that the bot is not "too strong" for the (internal)
> dice to be fair.
for just "strong hint" but regardless, you fail to
understand the logical argument itself, which
doesn't require anyone to be "dice paranoid".
MK
Axel Reichert
Jun 23, 2023, 2:11:25 AM6/23/23
to
MK <mu...@compuplus.net> writes:
> The idea was to prevent the bot from looking at the upcoming dice
> rolls before it makes its cube decision.
See roll.c for whether this happens.
> The idea was to prevent the bot from looking at the upcoming dice
> rolls before it makes its cube decision.
> idea is to give each dice roll to the bot after
> it finishes its cube decision.
Axel
Axel Reichert
Jun 23, 2023, 2:20:47 AM6/23/23
to
MK <mu...@compuplus.net> writes:
> On June 22, 2023 at 3:14:24 PM UTC-6, Axel Reichert wrote:
>
>> https://en.wikipedia.org/wiki/Anonymous_pipe
>
> Philippe was talking about "named pipes" and
> you give a link to "anonymous pipes". They are
> not the same.
Thanks. I know how pipes work. I was thinking about referring you to
> On June 22, 2023 at 3:14:24 PM UTC-6, Axel Reichert wrote:
>
>> https://en.wikipedia.org/wiki/Anonymous_pipe
>
> Philippe was talking about "named pipes" and
> you give a link to "anonymous pipes". They are
> not the same.
https://en.wikipedia.org/wiki/Pipeline_(Unix)
instead, which covers the general case, but could already hear your
complaints: "I asked about Windows".
> Why do you always complicate the discussion with things that are
> not essential to the subject..? :(
anonymous, so who is complicating the discussion?
Anyway, it is (again) time to temporarily lower your score for half a
year or so. rec.games.backgammon will be much more pleasant this way.
Axel
MK
Jun 23, 2023, 5:33:27 AM6/23/23
to
On June 23, 2023 at 12:11:25 AM UTC-6, Axel Reichert wrote:
> MK <mu...@compuplus.net> writes:
>> The idea was to prevent the bot from looking
>> at the upcoming dice rolls before it makes its
>> cube decision.
> See roll.c for whether this happens.
Don't you think Philippe was smart enough to
> MK <mu...@compuplus.net> writes:
>> The idea was to prevent the bot from looking
>> at the upcoming dice rolls before it makes its
>> cube decision.
> See roll.c for whether this happens.
tell me this..!?
You seem to be too dense to follow what was
said for what reason during the discussion. :(
Go back to the beginning of the thread and read
slowly, carefully; making an effort to give the
other guy some credit for having a good reason
to have said what he has said.
>> idea is to give each dice roll to the bot after
>> it finishes its cube decision.
> The bot asks for the dice roll after its cube
> decision, see roll.c.
MK
MK
Jun 23, 2023, 5:50:46 AM6/23/23
to
On June 23, 2023 at 12:20:47 AM UTC-6, Axel Reichert wrote:
> MK <mu...@compuplus.net> writes:
>> On June 22, 2023 at 3:14:24 PM UTC-6, Axel Reichert wrote:
>>> https://en.wikipedia.org/wiki/Anonymous_pipe
>> Philippe was talking about "named pipes" and
>> you give a link to "anonymous pipes". They are
>> not the same.
> Thanks. I know how pipes work. I was thinking
> about referring you to
> https://en.wikipedia.org/wiki/Pipeline_(Unix)
I couldn't read your mind to know what you had
> MK <mu...@compuplus.net> writes:
>> On June 22, 2023 at 3:14:24 PM UTC-6, Axel Reichert wrote:
>>> https://en.wikipedia.org/wiki/Anonymous_pipe
>> Philippe was talking about "named pipes" and
>> you give a link to "anonymous pipes". They are
>> not the same.
> Thanks. I know how pipes work. I was thinking
> about referring you to
> https://en.wikipedia.org/wiki/Pipeline_(Unix)
intended. I can only go by what you wrote. But
this isn't even critical to show you don't know
how pipes work, neither in Unix nor Windows.
> instead, which covers the general case, but
> could already hear your complaints: "I asked
> about Windows".
that the implementation if the same in both.
>> Why do you always complicate the discussion
>> with things that are not essential to the subject..? :(
> It is not essential to your subject whether the
> pipes are named or anonymous, so who is
> complicating the discussion?
because only their child processes can read
from them.
Named pipes can be blocked or not depending
on the parameters specified when opening and
writing/reading them. If they are not blocked,
then the reader can get an EOF as I had said in
my previous post.
I don't know how Noo-BG reads a pipe. I would
guess that in unblocked mode like a text dice
file. Phillip may know. Ask him. Also ask him
why he gave an exaample using named pipes.
You may lean something... You don't know
what you are talking about and still insist to
waste everyone's time with your Wikipedia
knowledge... :(
> Anyway, it is (again) time to temporarily
> lower your score for half a year or so.
> rec.games.backgammon will be much
> more pleasant this way.
there is always the adage to take one's own
advice. Thus, I figure that I can't go too much
wrong by giving it to you...
MK
Benno Maul
Nov 25, 2023, 9:29:51 AM11/25/23
to
Just one idea if you want to use your "own" dice. You could use the manual dice and an AHK Autohotkey script to observe, when the dice input window opens then the script runs any random generator to determine the row and column to perform a mouseclick to choose the dice.
MK
Nov 25, 2023, 10:39:51 PM11/25/23
to
this and I never said it couldn't be done sending
mouse clicks but only pointed out how sending
key strokes is so trivially easier, even compared
to sending a single mouse click anywhere on a
window.
Noo-BG windows, including the dice input dialog,
are resizable and/or relocatable which makes it
so much harder to determine the coordinates of
dice images.
Have you ever tried it yourself? Do you have a
working script that you can share?
MK
Benno Maul
Nov 26, 2023, 12:58:02 PM11/26/23
to
#NoEnv
SendMode Input
#Persistent
Rows := [95,185,275,365,455,545]
Columns := [152,302,452,602,752,902]
SetTimer, ActiveDice, 500
return
ActiveDice:
if WinExist("GNU Backgammon - Dice")
{
Random, randX, 1, 6
Random, randY, 1, 6
MouseClick , Left , Columns[randX], Rows[randY]
Sleep 2000
}
return
MK
Nov 26, 2023, 7:06:34 PM11/26/23
to
On November 26, 2023 at 10:58:02 AM UTC-7, Benno Maul wrote:
> MK schrieb am 26. November 2023 um 04:39:51 UTC+1:
>> Noo-BG windows, including the dice input dialog,
>> are resizable and/or relocatable which makes it
>> so much harder to determine the coordinates of
>> dice images.
>> Have you ever tried it yourself? Do you have a
>> working script that you can share?
Your sample script won't work as is. It will require a
lot more effort to make it work even if windows stay
static in location and size.
> You have to adjust the Rows and Columns to your
> screen and window size.
You probably found the rows/colums array constants
using a utility or script which is additional effort even
if your windows remain always static.
Also, I'm not sure if screen size matters but you need
to set the "CoordMode" relative to the active control,
(excluding the window title), instead of to the default
which is relative to screen, to begin with.
> The problem is, that the Dice window contains
> different text. For example the opening throw.
Yes, opening roll window is wider due to vertical text
added but things may still work since dice icons are
wide enough. Yet this is not the only nor the worst of
your problems that you would have discovered if you
had actually tried to come up with a "working" code.
> But when you have set it to the center of the buttons
> it should work everytime.
I don't know what you mean by this nor how you would
accomplish it, which obviously would require still more
effort, but it won't work anyway.
If everything in the dice dialog resized proportionately,
you could change your rows/colums array constants
to percentages of the window size, which you would
have to find using the ControlGetPos function that in
itself being yet additional effort; (and that in addition
to figuring out the incremental ratios from Noo-BG's
documentation or source code which may take quite
more time and effort also).
But what is worse is that, when you resize Noo-BG's
main window, the dice window resizes automatially
also yet the dice icons don't resize at the same rate
as the spaces and other items around them. (I could
but I won't bother to mention that the dice window
can be resized only vertically or only horizontally since
that would almost never happen and since the above
problems are already enough to make creating a AHK
script, (or any other script), an impossible task.
With all this said, it's beyond comprehension why the
mother-loving stubborn jerks of the Noo-BG team are
refusing to implement keyboard imput for dice rolls,
which would take adding a minimal and trivial code.
MK
> MK schrieb am 26. November 2023 um 04:39:51 UTC+1:
>> Noo-BG windows, including the dice input dialog,
>> are resizable and/or relocatable which makes it
>> so much harder to determine the coordinates of
>> dice images.
>> Have you ever tried it yourself? Do you have a
>> working script that you can share?
> Something like this. Hope this helps.
"Something like this" is hardly a good enough effort.
Your sample script won't work as is. It will require a
lot more effort to make it work even if windows stay
static in location and size.
> You have to adjust the Rows and Columns to your
> screen and window size.
using a utility or script which is additional effort even
if your windows remain always static.
Also, I'm not sure if screen size matters but you need
to set the "CoordMode" relative to the active control,
(excluding the window title), instead of to the default
which is relative to screen, to begin with.
> The problem is, that the Dice window contains
> different text. For example the opening throw.
added but things may still work since dice icons are
wide enough. Yet this is not the only nor the worst of
your problems that you would have discovered if you
had actually tried to come up with a "working" code.
> But when you have set it to the center of the buttons
> it should work everytime.
accomplish it, which obviously would require still more
effort, but it won't work anyway.
If everything in the dice dialog resized proportionately,
you could change your rows/colums array constants
to percentages of the window size, which you would
have to find using the ControlGetPos function that in
itself being yet additional effort; (and that in addition
to figuring out the incremental ratios from Noo-BG's
documentation or source code which may take quite
more time and effort also).
But what is worse is that, when you resize Noo-BG's
main window, the dice window resizes automatially
also yet the dice icons don't resize at the same rate
as the spaces and other items around them. (I could
but I won't bother to mention that the dice window
can be resized only vertically or only horizontally since
that would almost never happen and since the above
problems are already enough to make creating a AHK
script, (or any other script), an impossible task.
With all this said, it's beyond comprehension why the
mother-loving stubborn jerks of the Noo-BG team are
refusing to implement keyboard imput for dice rolls,
which would take adding a minimal and trivial code.
MK
0 new messages