On Tuesday, 2 February 2021 at 13:30:04 UTC, kevin arbuthnot wrote:however, I did start to be surprised by a few things.
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,
stupid moves in order to lose.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
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. MySecond, 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
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 winningUsing Gnu's own analysis tool, about 4 times out of 5 Gnu enjoys more "luck" than I did, often in the 20% range!There seem to be a lot of these old posts being resurrected recently.
I also think that the analysis tool should show a total pip count thrown by each player for each game; that reveals a lot.
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.
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 awinning 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.
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 awinning 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.
Thunderground Samurai schrieb am Dienstag, 31. August 2021 um 19:23:53 UTC+2: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.
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
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.
On Wednesday, September 22, 2021 at 12:46:47 PM UTC-7, Frank Berger wrote: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.
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
automatically when you don't land a hit pip?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 basicallyEven 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.
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?
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
The program wins far too often considering its otherwise suspect tactics. GnuBG plays a PR of about 0,45 (IIRC) and there are about 10 human players worldwide able to play below 3 on average (less is better) and no one of them regards GnuBG as using "suspect tactics". So either you are better player than the best we know (BTW How many major tournament and international titles you have won already? ) Or you might misjudge your abilities. I can't decide what I regard as more probable.
Moving pips forward instead of pulling them off? Doubling basically automatically when you don't land a hit pip?It would be very helpful to have an example. Than you might get an explanation.
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?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. If you play enough games you'll realize that GnuBG plays better than you might expect. Another approach would be to try to understand
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?
Ricardo Costa <hdvpro...@gmail.com> writes:Where is the setting for manual dice? I'm not seeing it. Thank you.
The program wins far too often considering its otherwise suspectMaybe it is YOUR tactics that is 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?Yes, set it to manual dice, roll your own (precision dice, please), do
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.
Where is the setting for manual dice? I'm not seeing it.
Ricardo Costa <hdvpro...@gmail.com> writes:Where is the setting for manual dice? Thank you.
Where is the setting for manual dice? I'm not seeing it.Several of the buzz words already match:
Settings, Options, Dice, Manual Dice
And please also google "All about GNU Backgammon".
Axel
On Monday, June 12, 2023 at 2:36:58 PM UTC-7, Axel Reichert wrote:Sorry, I misread your post. I see you answered the question. Thank you.
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:
Settings, Options, Dice, Manual Dice
And please also google "All about GNU Backgammon".
AxelWhere is the setting for manual dice? Thank you.
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?
P.S.: If you are serious in your endeavour,
there is also an official complaint form for
backgammon software, easily googled.
And how stupid so many people must have
been for such a long time, not finding the
cheating code in GnuBG
GnuBG plays a PR of about 0,45 (IIRC) and
there are about 10 human players worldwide
able to play below 3 on average ....
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.
Another approach would be to try to understand
what a pseudo-random-number generator is and
what a seed is.
...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,
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...
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 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.
- 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.
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.
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..?)
It's very possible that people who may have
looked for it weren't capable of finding it.
Without allowing keyboard input, it's impossible
to automate manual dice which is very tedious
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.
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.
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.
(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.
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.
I tend to think that mixing keyboard and
mouse use would be more cumbersome.
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.
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.
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.
https://en.wikipedia.org/wiki/Anonymous_pipe
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.
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.
Why do you always complicate the discussion with things that are
not essential to the subject..? :(
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)
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..? :(
It is not essential to your subject whether the
pipes are named or 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.
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.
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.
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.
On November 25, 2023 at 7:29:51 AM UTC-7, Benno Maul wrote:
Just one idea if you want to use your "own" dice.Thanks for the idea. I posted a few times about
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.
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
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.
You have to adjust the Rows and Columns to your
screen and window size.
The problem is, that the Dice window contains
different text. For example the opening throw.
But when you have set it to the center of the buttons
it should work everytime.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 243:19:34 |
| Calls: | 6,625 |
| Calls today: | 1 |
| Files: | 12,175 |
| Messages: | 5,320,255 |