Because I don't think it is the engines business to decide if it wants to kibitz or not. That should be a GUI task.
There is already an information stream of this kind of info from GUI to engine. It is called Thinking Output. Duplicating that stream is simply bad design. It should be the GUI (under user control) that decides what to do with this information. (Whether it appears in the message field, Engine Output window, PGN file, or is sent to the ICS.)
Engines can print whatever info they want in WB thinking output, as the PV field is free format. So there is no need for any protocol extension, all eeds are already accounted for.
WCRCC 2009
Moderators: hgm, Rebel, chrisw
-
hgm
- Posts: 27810
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
michiguel
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: WCRCC 2009
But the specific information sent is the engine's responsibility. On one hand you are asking the authors to kibitz in a specific format but in the other you say that this is GUI task. I am confused, if you extract the info from the thinking output, what are you asking from the authors then?hgm wrote:Because I don't think it is the engines business to decide if it wants to kibitz or not. That should be a GUI task.
There is already an information stream of this kind of info from GUI to engine. It is called Thinking Output. Duplicating that stream is simply bad design. It should be the GUI (under user control) that decides what to do with this information. (Whether it appears in the message field, Engine Output window, PGN file, or is sent to the ICS.)
Engines can print whatever info they want in WB thinking output, as the PV field is free format. So there is no need for any protocol extension, all eeds are already accounted for.
Miguel
-
hgm
- Posts: 27810
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: WCRCC 2009
I am asking from the authors to use WinBoard -autoKibitz, or, if they don't want to do that for any reason (e.g. they prefer another GUI, or do not want to use -autoKibitz because they dislike the other effects it has), make sure that what they send to the ICS is indistinguishable from what -autoKibitz would send.
That is not really asking much from the authors, but there are other paties involved:
* Tournament directors will have to step forward and require a standard format for kibitz info, so that GUIs that support kibitzing can comply with it and all understand each other.
* GUI writers will have to implement that format.
* If kibitz info is to be derived from Thinking Output, and TDs require info to be kibitzed that is not required by the specs of the engine protocol's Thinking Output, (e.g. tablebase hits in WB protocol), engine authors must make their engine volunteer that info (e.g. as leading part of the PV, so the GUI can relay it together with the PV, to comply with the tournament requirements).
I think it is possible to still leave the authors a lot of "artistic freedom" in what they want to kibitz in addition to the bare minimum required by the TD. A GUI -autoKibitz function will only have to extract the info of the defined Thinking Output fields score, dept, time, and nodes, and pack that in a recognizable form, such as:
!!! score/depth (nodes) PV
The PV field could in fact contain anything the author wishes, prefixed to the real PV. It would be upto the TDs to enforce the "!!! score/depth" part of the kibitz message, because that is what we want the ICS, opponent GUI or observer bots to capture for inclusion in the PGN, and to enforce that the rest of the message complies with their conditions. (The GUI would just pass that part on without processin, either on the sending or receiving end.)
That is not really asking much from the authors, but there are other paties involved:
* Tournament directors will have to step forward and require a standard format for kibitz info, so that GUIs that support kibitzing can comply with it and all understand each other.
* GUI writers will have to implement that format.
* If kibitz info is to be derived from Thinking Output, and TDs require info to be kibitzed that is not required by the specs of the engine protocol's Thinking Output, (e.g. tablebase hits in WB protocol), engine authors must make their engine volunteer that info (e.g. as leading part of the PV, so the GUI can relay it together with the PV, to comply with the tournament requirements).
I think it is possible to still leave the authors a lot of "artistic freedom" in what they want to kibitz in addition to the bare minimum required by the TD. A GUI -autoKibitz function will only have to extract the info of the defined Thinking Output fields score, dept, time, and nodes, and pack that in a recognizable form, such as:
!!! score/depth (nodes) PV
The PV field could in fact contain anything the author wishes, prefixed to the real PV. It would be upto the TDs to enforce the "!!! score/depth" part of the kibitz message, because that is what we want the ICS, opponent GUI or observer bots to capture for inclusion in the PGN, and to enforce that the rest of the message complies with their conditions. (The GUI would just pass that part on without processin, either on the sending or receiving end.)