1. Forum
  2. Usenet
  3. REC.GAMES.BACKGAMMON

  • Another Gnubg bug, show higher die on left

    From MK@21:1/5 to All on Wed Jan 11 12:13:22 2023
    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)
  • From Philippe Michel@21:1/5 to [email protected] on Thu Jan 12 22:10:39 2023
    On 2023-01-11, MK <[email protected]> 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)
  • From MK@21:1/5 to Philippe Michel on Thu Jan 12 18:12:41 2023
    On January 12, 2023 at 3:10:40 PM UTC-7, Philippe Michel wrote:

    On 2023-01-11, MK <[email protected]> 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)
  • From Philippe Michel@21:1/5 to [email protected] on Sat Jan 14 23:58:22 2023
    On 2023-01-13, MK <[email protected]> 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)
  • From MK@21:1/5 to Philippe Michel on Sat Jan 14 19:00:37 2023
    On January 14, 2023 at 4:58:23 PM UTC-7, Philippe Michel wrote:

    On 2023-01-13, MK <[email protected]> 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)