A van Kessel
Thu, 18 Jul 2002 11:46:21 +0200 (CEST)
|> Some comments on the 2nd gtp V2 draft:
|Thanks. I'll just add a few random responses at this time. Well, maybe
|> 3.2.1 move
|> maybe "Resign" should be added as a valid move.
|Pass and resign are troublesome. I decided to include pass in the
|vertex entity but sometimes it doesn't make any sense like in a list
|of handicap stones. Resign on the other hand only really makes sense
|as a response from genmove, so I added that explicitly as a
|possibility for that command.
Maybe in the "basic types" section:
vertex := %c%u
move := vertex|pass|resign
( handicap_list would of course be vertex* )
That would solve it, IMO.
Wanting resign allowed an argument for play, is
a matter of symmetry. I'll seek help :-)
|> I think the PL and MN are (invisible) aspects
|> of the board state. PL should be made explicit,
|> MN is less important.)
|explicitly include color in the play and genmove commands. This is a
|definitive decision for GTP version 2.
I rest my case.
|Absolutely not. The only sane way to communicate ko information is by
|playing through the game so far. If superko is used it's also the only
For superko, I agree.
For simple Ko there is only a need for it if a
setup (AB AW) command is available. That seems
to have been removed from the protocol(draft).
But I agree, one can always work around it by stepping
through the last move.
|> IMO, The regression subset is not needed (for general use)
|> and should be consired an extension.
|You're underestimating the value of using GTP for regressions and the
|potential for sharing well defined test suites between programmers. I
|would have excluded this except for the fact that I consider it
There is only a need for a standard if there is more than
one program that implements it.
A subset can be managed seperate from the core standard, but
still care must be taken not to change the semantics needlessly.
For very obvious entities (territory, evaluation) there will
probably be shared semantics between implementations.
For others (influence, rabbit-move-reasons) there will be not.
|loadsgf is not in the core set for two reasons:
|1. GTP and SGF don't really fit very well. SGF has a complexity and
| power of expression which isn't met by GTP.
most implementations will need some SGF functionality.
Whether this be in the core set, or in a separate unit is
|2. loadsgf requires the controller and the engine to have a common
Commands are allowed to fail.
|> I don't see much need for renaming the V.1 "help" command
|A matter of taste apparently. I think "help" is more ugly.
It is not just about uglyness. It is about bloat.
Should I Implement both commands ?
Should I include a "version" field in my command table ?
|I considered that alternative but I don't really like the "gen"
|abbreviation. Does anyone else have an opinion on the naming of these
|commands, or maybe a better proposal?
To me it is very confusing, I have to reread both monographs
every time to see which is which.
Gen_free_handicap may be ugly, but it definitely breaks ambiguity.
|> 6.3.3 play/genmove
|Pass is already valid. (See definitions of vertex and move entities.)
|Resign is an explicit possibility for genmove but would it really make
|sense for play?
Sorry, makes few sense. Protocol symmetry ?
Maybe the engine could ring a bell and increment a
counter when receiving a "resign" :-)
|> To facilitate automated playing, a command to report dead stones
|> could be added. eg: "list_dead_stones B"
|This can be done with the not yet documented "final_status_list"
I prefer simple commands which do one thing.
The final_status_list (what I've seen of it)
was a kludge of subcommands.
|What is the problem with these? If the engine wants to use move number
|for some purpose it may change that state however it likes. I don't
|see why the controller or the protocol should care.
I am a state freak, I guess.
|Player to move is a non-issue by design.
For an engine, it might. for a GP program it is very important.
|> [error] GMP uses a one-dimensional vertex
|> coding scheme. 1 bit color + 9bits lineair addres, IIRC.
|Yes, but it also associates this linear address with 2D coordinates
|which are elsewhere used to define the fixed handicap placement.
Not relevant. The topic is protocol, not program.
|> [politics] Why mention IGS and not NNGS, KGS ?
You missed a :-) here.
Maybe I omitted one. Yeah, I moved it to the protocol.Z part.
Snipped nicely :-)
|Actually I'd like to know which servers do use this convention and
|whether there are some which don't. I only regularly use NNGS, so my
|knowledge is rather limited here.
|Similarly I later have the comment "This fixed handicap placement is
|compatible with the Go Modem Protocol and many go servers." This is
|intentionally vague because I don't really know about IGS or other
|servers than NNGS. Furthermore NNGS is only almost compatible. It
|deviates, probably due to some obscure bug, for 2 and 3 handicap
|stones on an 8x8 board. Any information about how other servers do
|would be most welcome.
People actually play 8x8 ? I'll give NNGS a peek.
I think, communicating a vertex in %c%u format is pretty standard.
Just stay with the hurd...
Kiseido: Propriety ?
I am not aware of any free-handicap implementation. Just passing
will do for most cases.
But, the real reason for wanting it in the protocol, is
cause of the HA in the game record, I guess. For the rest,
the position can just be set up (by AB,AW, play)
, and komi set seperately.
|> that others (than gnugo) will ever use them.
|Not so. There already are other people using them.
Then you'll have to preserve their semantics in
future versions :-[