On Mon, 2007-07-16 at 11:16 -0400, Jason House wrote:
>
>
> On 7/16/07, Don Dailey <[EMAIL PROTECTED]> wrote:
> The client itself knows the game is over, it's just not
> transmitted to
> the engine.
>
> One way to deal with this is to make the client send a quit
> command. I
> think some program would like to quit and be restarted before
> and after
> each game.
>
> As a quick hack, it's trivial to add one line to the
> cgos3.tcl script
> to
> send gameover by itself - or even gameover with a a reason
> e.g.
>
> gameover W+resign
>
> Is that the format of the KGS command? I really hate to mix
> and match
> GTP extensions - but it's probably ok. I think what I would
> do is make
> a cgos-game_over command, mimick the KGS behavior and use the
> kgs
> version if the cgos version doesn't exist.
>
>
> Actually, the kgs-game_over gives no arguments. It's simply intended
> to let the engine know that a game is truly over. It could be because
> the opponent escaped and didn't return in time (5 minutes), or because
> of a real game ended. In some configurations, kgs will send a
> clear_board command in the middle of a game (as a way of handling
> undo, even if the engine doesn't support it).
>
> The idea is that the engine can shutdown and disconnect cleanly from
> the server in response to the command.
So what I will do is implement cgos_gameover which gives a reason.
I will also honor the kgs-gameover version when the cgos version is not
supported.
This is a debugging aid. It's nice to put in the log file for you
engine what the score (or reason) was for winning or losing.
>
> Would anyone find it useful to have an option to kill and
> restart the
> engine between games?
>
>
> I would. It could even be used as an opportunity to go run on another
> server for a bit (discussed previously). I guess if this option was
> done, however, a small delay between the end of the last game and the
> start of the next round would be needed. Otherwise, the two players
> in the final game would miss the next round on the server if they take
> the opportunity to shut down.
There is a several second delay. But it doesn't matter, I don't
remember the details but the client does the right thing if you exit
properly, with a sentinal file. There is no race condition that will
cause you to lose a game. I seem to remember that you must respond to
a command before you will get scheduled for the next round, even if you
don't disconnect.
In fact, the answer to my bug MAY have been answered in my response to
you! I have had it happen that my client and program are logged in to
the server, but it isn't being scheduled to play - ever (but other games
are.) I'm thinking it is in limbo - for whatever reason didn't respond
to the gameover command (or whatever it is CGOS is looking for) and yet
it remains on-line. Perhaps this is causing a general problem where no
games can get scheduled. I will take a look.
>
>
> On top of this, I have been intending to add one more GTP
> extension -
> one to send the name and rating of the players. This can be
> done on
> the client side without any changes to the server. Here is
> what I had
> in mind:
>
> cgos_gameinfo FatMan(1800) ggmc-x86-1.3Q(2008)
>
> It would be up to your program to parse this. extract the
> ratings if you
> wanted this separate and determine which is the opponent.
> This would
> be sent on setup,
> either at the beginning of a game or after a disconnect and
> restart.
>
> Personally, I'd prefer the ratings to be separate inputs... Sticking
> to the KISS principle that seems to be used with most other gtp
> commands.
I hate to separate this, they go together in a natural way. You
probably would not implement one without the other. GTP used to have a
separate genmove command for each color and combined them and I can't
see having 4 commands or even 2. I also don't want to have to hit
programmers with several commands to be implemented.
However, it might be good to separate the ELO rating by making this
command have 4 parameters instead of 2:
cgos_gameinfo FatMan 1800 ggmc-x86-1.3Q 2008
Even though this will always be a cgos extension due to the fact that it
is a cgos rating, I wouldn't mind getting the opinion of the GTP
creators on whether they consider one form more correct than another.
One could imagine adding extra parameters such as the color and doing it
like this:
cgos_gameinfo white FatMan 1800
cgos_gameinfo black ggmc-x86-1.3Q 2008
or
cgos_gameinfo white name Fatman
cgos_gameinfo white elo 1800
... etc
or separate commands like you propose:
cgos_white-elo
cgos_white-name
cgos_black-elo
cgos_black-name
or cgos_name white Fatman
cgos_elo white 1800
If Gunnar gives his opinion, I will probably take his advice.
> Is there any way to give an indication of which one is the engine
> receiving the command?
I don't want to complicate things too much but this is possible because
the client knows the name of the program that logged in. It could be
implemented without any change to the server, which is what I prefer.
I'm not sure whether it's really a good thing or not and I want to be
stingy about adding GTP commands. Your bot could determine which
color it was if you pass the name via a command line argument to your
bot:
./mybot -gtp -playing-as "JoeBot" -level 10 ...etc
- Don
> If it's not self, opponent, I'd guess it'd be black, white. In that
> case, It may be good to pass the color that the engine is to play.
> That avoids having to code the engine to detect whatever crazy id
> strings the author comes up with down the road.
>
>
> _______________________________________________
> computer-go mailing list
> [email protected]
> http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
