In "Settings, Options, Dice", there is a checkbox
that says "Show higher die on left", which sets
the "set gui highdiefirst" value in "gnubgautorc"
to "on" or "off" but regardless which you select,
brown lily shows the higher die on left anyway.

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-01-11, MK <murat@compuplus.net> wrote:

In "Settings, Options, Dice", there is a checkbox
that says "Show higher die on left", which sets
the "set gui highdiefirst" value in "gnubgautorc"
to "on" or "off" but regardless which you select,
brown lily shows the higher die on left anyway.

highdiefirst set to off doesn't imply the lower die will be show first,
but that the dice will be shown as they are stored in gnubg's internal
move list.

But when the roll is generated through gnubg (including manual dice or
dice read from a file), it is "normalized" as <high die>,<low die>.

The only case where you will see the lower die first about half of the
time is when you import a match from an online site or another
backgammon program that doesn't sort the dice as gnubg does. It will
never happen when you actually play.

I'm not sure what point you're trying to make, but if it is that the highdiefirst option is esentially useless, I would agree.

Moreover I think that we should normalize the dice when importing a
match as well. I raised the idea with Michael Petch years ago. He
disagreed (I don't remember why) and I didn't insist.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On January 12, 2023 at 3:10:40 PM UTC-7, Philippe Michel wrote:

On 2023-01-11, MK <mu...@compuplus.net> wrote:

to "on" or "off" but regardless which you select,
brown lily shows the higher die on left anyway.

The only case where you will see the lower die
first about half of the time is when you import
a match from an online site or another
backgammon program that doesn't sort the
dice as gnubg does.

I tried to manually edit and import text files with
the low die first but Gnubg shows high die first
in the game record...

I'm not sure what point you're trying to make,
but if it is that the highdiefirst option is esentially
useless, I would agree.

It sure looks like a GUI setting on how to paint the
dice on the board. I took a quick look at gtkboard.c
It seems the variable fGUIHighDieFirst is hard coded
set to "true" and so the dice is always swapped but
there may be more to it than what I could see in a
couple of minutes. It just doesn't make sense that
it was put there to select how the dice are recorded
in the move list.

Moreover I think that we should normalize the
dice when importing a match as well.

It seems to be doing that already. BTW, I find it
very strange to call that "normalizing the dice"...

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-01-13, MK <murat@compuplus.net> wrote:

I tried to manually edit and import text files with
the low die first but Gnubg shows high die first
in the game record...

Te game record is a different thing. There, I think it is natural to
show the higher die first. The rolls are printed this way everywhere, in
books, etc...

It sure looks like a GUI setting on how to paint the
dice on the board.

After thinking about it further, I now agree you're right. The current behaviour is either buggy or its logic is badly unintuitive. It really
should be:
highdiefirst on -> higher die first
highdiefirst off -> random order, whatever the roll's recording is

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On January 14, 2023 at 4:58:23 PM UTC-7, Philippe Michel wrote:

On 2023-01-13, MK <mu...@compuplus.net> wrote:

I tried to manually edit and import text files with
the low die first but Gnubg shows high die first
in the game record...

Te game record is a different thing. There, I think
it is natural to show the higher die first. The rolls
are printed this way everywhere, in books, etc...

I don't care how everyone does it. I'm nor trying to
change how they/you do it. I really have difficulty
communicating with you.

You said I could see the dice "not normalized" (in
your words) if I were to import matches with "non
normalized" dice. So, after importing, where would
I look and see "not normalized" in Gnubg?

It sure looks like a GUI setting on how to paint
the dice on the board.

After thinking about it further, I now agree you're
right.

Ohh, wow! This is the first time you acknowledged
that I'm right on anything for a long time. :)

The current behaviour is either buggy or its logic
is badly unintuitive. It really should be:
highdiefirst on -> higher die first
highdiefirst off -> random order, whatever the roll's
recording is

I documented what the problem was and stopped
short of telling you how to fix it in the code. Your
still blabbering about it indicates to me the level
incompetency of the "Gnubg team" and explains
why Gnubg hasn't been going anywhere for many
years. So, let me try to help you further. It's so
simple, I can do it from memory without needing
to look at anything again.

It looks like incomplete implementation of a new
feature. Gnubg probably always swapped the high
die and they wanted to add an option for the user
to not do it. They added the checkbox to the GUI
and the logic to set the "gui highdiefirst" value in
"gnubgautorc" to "on" or "off" accordingly. This part
works just fine!

In "gtkboard.c" the variable "fGUIHighDieFirst" is
references three times, once to set it to "true"
unconditionally and twice to check it to decide to
whether to swap the dice as part of implementing
the feature as intended.

The only thing you need to do is set "fGUIHighDieFirst"
*conditionally*, i.e.

if "highdiefirst" = "on" then "fGUIHighDieFirst" = "true"
else "fGUIHighDieFirst" = "false"

and everything will work just fine as was intented.

BTW: I'm now wondering if none of my suggestions
got implemented simply because the Gnubg team
was just not capable of doing it..? :(

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)