Winboard Forum

I suggest to introduce a command to CECP that does the same as tellopponent, but from GUI to the engine. It could be named "tellfromuser"/"talk"/"usertalk"/"usertell"/... and would simply have a free text parameter. I'm only asking for an addition to the CECP document, not an implementation in Winboard/XBoard.

When connecting a chess engine to FICS through Winboard/XBoard, the chess engine can talk to opponents using "tellopponent", but cannot ever receive chat talk from them. Some interfaces even provide an always-visible chatbox also for local games (e.g. PyChess) which the user could use to respond to the engine, but again the protocol doesn't allow an engine to receive that right now.

I'm not saying a lot of engine developers would use it, but since I added FICS support to my engine I also wrote a simple chat functionality for fun, and now I find it kinda sad that interfaces allow my engine to tell the player something, but don't offer a way for the player to text back to the engine. Shouldn't that be changed?

I guess most other engine developers don't care, so that is why I'm mainly asking for a standardization right now so that people who are interested in it (like me) can actually implement it into engines or interfaces.

--
PS: Xboard/Winboard should probably also move away from message popups for chat talk from the engine to the user and add some sort of simple chat window for talking to the opponent (which could be shared with FICS where it is of more practical use I guess), where it could one day additionally allow user->engine talk with this new CECP command.

An interesting idea, and I in fact have already an application waiting for it: the peer-to-peer pseudo-engine (p2p.exe) now requires the user to enter a message for his opponent as a string option in the Engine #1 Settings dialog, and press a Send button there. Very cumbersome, and not really suitable for intensive chat. (I added it nevertheless to allow exchange of 'emergency mesages' with the reote player.)

Of course WinBoard already has all the functionality built in. It is just that you can only ask for chat boxes in ICS mode, and that it is grayed out otherwise. If the user could open chatboxes in engine mode, he could use the chatpartner field to select the type of engine chatter he wants to see there (used to match against the leading characters of the engine ouput line. Like '#' would show all engine debug output, and an empty chatpartner field would show all engine output. This would even be very useful for existing engines.

I guess this would be a good opportunity to start a discusssion about comments that might not be useful for an engine proper, but very important for 'pseudo-engines' that perform other tasks, disguised as engine. Like p2p, but also drivers for auto-response boards. For the latter it would be really useful if they could issue commands to the GUI, like setting up a position, or putting the GUI in particular mode to play against engine. In the WB Alien protocol I defined a highlight protocol, that an engine could use to put colored highlight markers on board squares, in response to user mouse actions (of which it will be informed).

As for chatting, the logical way to do it would probably be like this:

Define a feature chatter=1 command that the engine can used to invite the GUI to send chat messges to it, through a chatter MESSAGE command. In ICS mode the GUI would then relay all shouts, tells, whispers and kibites that go around on the ICS to the engine. In engine mode it would be what the user types in a chatbox, which the GUI would allow the user to pop up for engines that had enabled this feature (in human-engine mode).

It could be useful to implement a move in GUIs that would send the chatter to another engine than the one that is playing. E.g. a dual-engine zippy mode, where the first engine is responsible for the Chess, and the second for conversation. But I guess that is really an independent issue; such a second engine could be generally useful, e.g. to provide analysis on what the first engine is doing in its games.

H.G.Muller wrote:Define a feature chatter=1 command that the engine can used to invite the GUI to send chat messges to it, through a chatter MESSAGE command. In ICS mode the GUI would then relay all shouts, tells, whispers and kibites that go around on the ICS to the engine. In engine mode it would be what the user types in a chatbox, which the GUI would allow the user to pop up for engines that had enabled this feature (in human-engine mode).

For ICS, it might be important to add a parameter for the source of the message which would be specified if the chatter is not the opponent but someone else (or to have a second command that has such a parameter). Count me in on feature chatter=1 engines

Indeed, the chatter from ICS would need two parameters. I think parameters would be preferable over multiplying the number of commands. So we could make the format for this case:

chatter HANDLE TYPE MESSAGE

with TYPE any member of the set { shouts, tells, says, whispers, kibitzes }. In fact I wonder if this should be defined in the WB protocol, or just imported from ICS protocol.

You could probably refer to the ICS protocol for the types, but define one universal type that is also present in a local game, e.g. "says" or whichever one you'd want to pick.

Also the engine would need to know the "handle" of the opponent, also for a local non-ICS game. If it is to be taken from the "name X" directive, the chatter command probably needs to allow for space characters in the handle which could make things a bit odd. Alternatively, you could add a new "handle X" directive which transmits a handle, and could be something like the opponent name with underscores in place of space chars for local games. But I don't like that too much either, because if the engine uses that handle to address you, a local player "Jason blubb" would suddenly get addressed as "Jason_blubb" which looks a bit odd.

What about a second command that doesn't need a type and handle for non-ICS games? There could be "chatter" (with no additional parameters, just the text - for local games where only the opponent can talk to the engine) and "chatterics" with type/handle parameters.

The engine can know if it is plaing on an ICS or not, so I figured the HANDLE TYPE parameters are only needed in that case, because otherwise there can only be one source. So in a sense as far as XBoard protocol is concerned TYPE and HANDLE are really part of the message. In local mode they would be omitted.

Hm. To be honest, I don't think changing parameters of a command (in a way that isn't obvious to detect, a text with many word might accidentially get parsed as handle, type, text) is such a good idea.

Engine devs might implement "chatter", then not bother with ICS support, and suddenly you got an engine that takes what everyone says on ICS including their handle and the message type as part of a literal text from a single opponent.
If an engine not caring about ICS implements chatter but not chatterics and all the other ics commands, it would be much less of a problem.

In that case I would rather add dummy arguments 'opponent' and 'says' in local mode. If I correctly understand ICS protocol, 'says' will be exclusively used for messages from your opponent.

Yup, dummy arguments sounds good. What about also giving "opponent" instead of the handle in ICS games for the opponent too? Then "opponent" would ALWAYS identify the opponent, no matter whether the game is an online game or not. The "name" command would still allow the engine to know the opponent's true name.

Then only the question how to deal with a user registering "opponent" as account handle on FICS remains

Thi is why I wanted to avoid putting a restriction on the handle. 'says' already indicates it is your opponent speaking, and ignore the handle. I don't think there is a need to handle the ICS case different fom the local one; an opponent is an opponent, no matter how he connects. An engine author only wanting to handle the local case can scanf for "chatter %*s says %[^\n]" to get the message.

Hm ok you're right. Probably "chatter opponent says blubb" is best for local mode, and ICS would be "chatter truehandleofopponent says blubb", and ICS-supporting engines would simply need to compare the handle and "name truehandleofopponent" when in ICS mode to find out if the message originated from the opponent and not some other unrelated person.

I don't think that on ICS it could come from anyone else, can it? With 'whisper' and 'kibitz' you are dealing with the group of observers, but 'say' is a one-to-one communication between the players.

Well technically, anyone could use say at any time (unrelated to whether you are participating with them in a match). Of course people not playing with you are unlikely to be doing it, but imho it should be taken into consideration. Also, the opponent can kibitz (correct me if that is inaccurate, I'm not on FICS that often).
But as long as the handle of the opponent is specified at the beginning of each game with "name handleofopponent", the engine shouldn't have trouble to tell opponents from random say-using persons.

I think the specs on "chatter" should actually contain an explicit requirement for GUIs implementing ICS to send "name XYZ" right before or after starting a new game with "new" (if in ICS mode) with XYZ being the opponent's handle so an engine can tell the opponent's messages apart from other people using "say". It seems to be an important detail that is easy to forget (when developing a GUI) if not pointed out explicitely..

EDIT: I just thought of something else. What if a chess server with a new online protocol emerges that allows space chars in user names? Wouldn't it be more future-proof if the chatter's "handle" parameter was made to support handles with space chars (e.g. by using " " around them)? While FICS might not be doing it, this scenario should be considered. As a side effect, this would also allow passing the actual specified user name (same as X in "name X" for local games) even if it contained space chars.

Right, I mixed up FICS' "say" and "tell". But we would also want to support tell, would we not? And tell is not restricted to the opponent (and the engine might want to be able to tell if it came from the opponent or not).