[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] GNUBG prev game and session list problems
From: |
Philippe Michel |
Subject: |
Re: [Bug-gnubg] GNUBG prev game and session list problems |
Date: |
Mon, 15 Apr 2019 23:11:18 +0200 |
User-agent: |
Mutt/1.11.4 (2019-03-13) |
On Fri, Apr 12, 2019 at 11:29:21AM +0200, Wolf Dieter Wall wrote:
> i am running gnubg with -t for the command line and i cannot understand how
> list session and prev game work, or how they should work.
>
> I have two session attached but it seems that
> - list session produces no output on money sessions
list session is not implemented (see the CommandListMatch() function in
play.c...
> - prev game 1 does not work after a game in the session ended
A workaround might be to use the "set automatic game off" at the
beginning of your session (but see below for other shortcomings). With
that you will stay in the just completed game until you issue a "next
game" command.
> - list game works as long as the game is in progress. afterwards status
> changes to "game over" and nothing more happens with the list game command.
It seems many of these commands have overly strict conditions on when
they can be issued. For "list game", for instance, it is
CommandListGame() in play.c and starts with the following check:
if (ms.gs != GAME_PLAYING) {
outputl(_("No game in progress (type `new game' to start one)."));
return;
}
The game state can be GAME_NONE, GAME_PLAYING, GAME_OVER, GAME_RESIGNED
or GAME_DROP and it looks like the game could be listed from all of them,
except possibly the first one (and even then displaying an empty moves
list would hardly be wrong).
I don't know why it was done this way. Maybe there were crashes when
accessing uninitialized data structures at the wrong time and the
developers at the time went extra careful ? These are parts of the code
that have been barely touched for 10 years or more.
I'm afraid these commands to go through the moves list from the CLI have
never been used much. Maybe they looked like a good idea at the time but
were somehow overriden by the GUI for the interactive side and by the
Python interface for the advanced scripting side.
Offhand, it looks like it would still be useful and not too difficult to
review the code for unwarranted "No game in progress, return" patterns
and fix them. The commands to switch from one game to another might be
trickier.